Is there a loss of entropy by hashing an N-bit random key to produce an N-bit hash?
Clash Royale CLAN TAG#URR8PPP
I read the following piece of code:
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
Apparently, this code was used as a trick to produce a hex string key from a 128-bit binary pseudo-random value.
Someone here claimed this is inherently insecure since it passes a cryptographically secure random value through an "insecure hash function".
On my side, I would say the collision flaws in md5 are irrelevant here since the hash function input and output have the same size. And so, the hash function output is as random as its input.
What's your opinion about that? Does hashing an N-bit random key to produce an N-bits hash change the randomness of the key?
hash random entropy
asked Feb 10 at 16:21
Sylvain LerouxSylvain Leroux
1638
add a comment |
I read the following piece of code:
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
Apparently, this code was used as a trick to produce a hex string key from a 128-bit binary pseudo-random value.
Someone here claimed this is inherently insecure since it passes a cryptographically secure random value through an "insecure hash function".
On my side, I would say the collision flaws in md5 are irrelevant here since the hash function input and output have the same size. And so, the hash function output is as random as its input.
What's your opinion about that? Does hashing an N-bit random key to produce an N-bits hash change the randomness of the key?
hash random entropy
asked Feb 10 at 16:21
Sylvain LerouxSylvain Leroux
1638
add a comment |
I read the following piece of code:
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
Apparently, this code was used as a trick to produce a hex string key from a 128-bit binary pseudo-random value.
Someone here claimed this is inherently insecure since it passes a cryptographically secure random value through an "insecure hash function".
On my side, I would say the collision flaws in md5 are irrelevant here since the hash function input and output have the same size. And so, the hash function output is as random as its input.
What's your opinion about that? Does hashing an N-bit random key to produce an N-bits hash change the randomness of the key?
hash random entropy
asked Feb 10 at 16:21
Sylvain LerouxSylvain Leroux
1638
I read the following piece of code:
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
Apparently, this code was used as a trick to produce a hex string key from a 128-bit binary pseudo-random value.
Someone here claimed this is inherently insecure since it passes a cryptographically secure random value through an "insecure hash function".
On my side, I would say the collision flaws in md5 are irrelevant here since the hash function input and output have the same size. And so, the hash function output is as random as its input.
What's your opinion about that? Does hashing an N-bit random key to produce an N-bits hash change the randomness of the key?
hash random entropy
hash random entropy
asked Feb 10 at 16:21
Sylvain LerouxSylvain Leroux
1638
asked Feb 10 at 16:21
Sylvain LerouxSylvain Leroux
1638
edited Feb 11 at 0:41
Sylvain Leroux
asked Feb 10 at 16:21
Sylvain LerouxSylvain Leroux
1638
asked Feb 10 at 16:21
Sylvain LerouxSylvain Leroux
1638
asked Feb 10 at 16:21
Sylvain LerouxSylvain Leroux
1638
1638
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Hashing is a deterministic process which means that it can never increase the randomness. But of course it can decrease the randomness: if you hash a 200 bit random value with some hash algorithms which only outputs 160 bits (like SHA-1) then of course the resulting value can never have 200 bits randomness.
But as long as the number of input bits is significantly lower than the output size of the hash it will not reduce the randomness, providing a cryptographic hash is used. If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash. And you are right that collision resistance does not matter for this.
answered Feb 10 at 16:37
Steffen UllrichSteffen Ullrich
118k13205273
Thanks for such a rapid answer, Steffen. Could you elaborate on this though: "If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash." Why a cryptographic hash still decreases, even slightly, the entropy if the hash size in the same as the input size?
– Sylvain Leroux
Feb 10 at 16:50
5
@SylvainLeroux: A cryptographic hash is not designed as a bijective mapping from N bit input to N bit output. This means that there will be some collision and thus the randomness will be slightly reduced.
– Steffen Ullrich
Feb 10 at 17:04
12
@SylvainLeroux You cannot be sure that all possible 128-bit inputs have different hashes, and they probably don’t. If it is so, then, after the hash, some 128-bit outputs are impossible and others have a higher occurrence than $1 over 2^128$.
– user2233709
Feb 10 at 17:05
Thanks for the clarification Steffen & @user2233709
– Sylvain Leroux
Feb 10 at 17:27
2
FWIW, I've got an estimate of the entropy loss here: crypto.stackexchange.com/q/67217/65808
– Sylvain Leroux
Feb 11 at 12:51
add a comment |
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
This is guaranteed to lose some entropy, but not much. The difficulty in attacking MD5 doesn't directly suggest the amount of loss, but merely tells us it is not zero.
If I fall back on naïve construction, I find that the entropy loss is can be computed from the fixed point probability of 63.21%. which in turn implies that less than one bit of entropy has been lost. I forget how much it is said you actually need, but I know 122 bits of true entropy is plenty.
On the other hand, what are you trying to accomplish here? dd if=/dev/urandom bs=16 count=1 is plenty by itself. There is no point in trying to use md5 in defending kekkak-f against weakness.
If you really feel the need to do something here, make a 128 bit application secret key, generate it in install time directly from /dev/random (not urandom), and xor it into the feed from /dev/urandom. But I don't see a single reason to lift a finger to do this.
answered Feb 11 at 2:42
JoshuaJoshua
72748
3
I think the md5sum was meant as a lazy way to get your 128 bits of randomness formatted as a hex string, without having to look up the syntax ofod.
– Nate Eldredge
Feb 11 at 4:13
@NateEldredge I suspect this was the intent of the sysadmin that wrote the code. The question was raised here, but from the various answers I've got, I doubt this was a deliberate attempt to weaken the key.
– Sylvain Leroux
Feb 11 at 12:48
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f203318%2fis-there-a-loss-of-entropy-by-hashing-an-n-bit-random-key-to-produce-an-n-bit-ha%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Hashing is a deterministic process which means that it can never increase the randomness. But of course it can decrease the randomness: if you hash a 200 bit random value with some hash algorithms which only outputs 160 bits (like SHA-1) then of course the resulting value can never have 200 bits randomness.
But as long as the number of input bits is significantly lower than the output size of the hash it will not reduce the randomness, providing a cryptographic hash is used. If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash. And you are right that collision resistance does not matter for this.
answered Feb 10 at 16:37
Steffen UllrichSteffen Ullrich
118k13205273
Thanks for such a rapid answer, Steffen. Could you elaborate on this though: "If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash." Why a cryptographic hash still decreases, even slightly, the entropy if the hash size in the same as the input size?
– Sylvain Leroux
Feb 10 at 16:50
5
@SylvainLeroux: A cryptographic hash is not designed as a bijective mapping from N bit input to N bit output. This means that there will be some collision and thus the randomness will be slightly reduced.
– Steffen Ullrich
Feb 10 at 17:04
12
@SylvainLeroux You cannot be sure that all possible 128-bit inputs have different hashes, and they probably don’t. If it is so, then, after the hash, some 128-bit outputs are impossible and others have a higher occurrence than $1 over 2^128$.
– user2233709
Feb 10 at 17:05
Thanks for the clarification Steffen & @user2233709
– Sylvain Leroux
Feb 10 at 17:27
2
FWIW, I've got an estimate of the entropy loss here: crypto.stackexchange.com/q/67217/65808
– Sylvain Leroux
Feb 11 at 12:51
add a comment |
Hashing is a deterministic process which means that it can never increase the randomness. But of course it can decrease the randomness: if you hash a 200 bit random value with some hash algorithms which only outputs 160 bits (like SHA-1) then of course the resulting value can never have 200 bits randomness.
But as long as the number of input bits is significantly lower than the output size of the hash it will not reduce the randomness, providing a cryptographic hash is used. If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash. And you are right that collision resistance does not matter for this.
answered Feb 10 at 16:37
Steffen UllrichSteffen Ullrich
118k13205273
Thanks for such a rapid answer, Steffen. Could you elaborate on this though: "If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash." Why a cryptographic hash still decreases, even slightly, the entropy if the hash size in the same as the input size?
– Sylvain Leroux
Feb 10 at 16:50
5
@SylvainLeroux: A cryptographic hash is not designed as a bijective mapping from N bit input to N bit output. This means that there will be some collision and thus the randomness will be slightly reduced.
– Steffen Ullrich
Feb 10 at 17:04
12
@SylvainLeroux You cannot be sure that all possible 128-bit inputs have different hashes, and they probably don’t. If it is so, then, after the hash, some 128-bit outputs are impossible and others have a higher occurrence than $1 over 2^128$.
– user2233709
Feb 10 at 17:05
Thanks for the clarification Steffen & @user2233709
– Sylvain Leroux
Feb 10 at 17:27
2
FWIW, I've got an estimate of the entropy loss here: crypto.stackexchange.com/q/67217/65808
– Sylvain Leroux
Feb 11 at 12:51
add a comment |
Hashing is a deterministic process which means that it can never increase the randomness. But of course it can decrease the randomness: if you hash a 200 bit random value with some hash algorithms which only outputs 160 bits (like SHA-1) then of course the resulting value can never have 200 bits randomness.
But as long as the number of input bits is significantly lower than the output size of the hash it will not reduce the randomness, providing a cryptographic hash is used. If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash. And you are right that collision resistance does not matter for this.
answered Feb 10 at 16:37
Steffen UllrichSteffen Ullrich
118k13205273
Hashing is a deterministic process which means that it can never increase the randomness. But of course it can decrease the randomness: if you hash a 200 bit random value with some hash algorithms which only outputs 160 bits (like SHA-1) then of course the resulting value can never have 200 bits randomness.
But as long as the number of input bits is significantly lower than the output size of the hash it will not reduce the randomness, providing a cryptographic hash is used. If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash. And you are right that collision resistance does not matter for this.
answered Feb 10 at 16:37
Steffen UllrichSteffen Ullrich
118k13205273
answered Feb 10 at 16:37
Steffen UllrichSteffen Ullrich
118k13205273
answered Feb 10 at 16:37
Steffen UllrichSteffen Ullrich
118k13205273
answered Feb 10 at 16:37
Steffen UllrichSteffen Ullrich
118k13205273
118k13205273
Thanks for such a rapid answer, Steffen. Could you elaborate on this though: "If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash." Why a cryptographic hash still decreases, even slightly, the entropy if the hash size in the same as the input size?
– Sylvain Leroux
Feb 10 at 16:50
5
@SylvainLeroux: A cryptographic hash is not designed as a bijective mapping from N bit input to N bit output. This means that there will be some collision and thus the randomness will be slightly reduced.
– Steffen Ullrich
Feb 10 at 17:04
12
@SylvainLeroux You cannot be sure that all possible 128-bit inputs have different hashes, and they probably don’t. If it is so, then, after the hash, some 128-bit outputs are impossible and others have a higher occurrence than $1 over 2^128$.
– user2233709
Feb 10 at 17:05
Thanks for the clarification Steffen & @user2233709
– Sylvain Leroux
Feb 10 at 17:27
2
FWIW, I've got an estimate of the entropy loss here: crypto.stackexchange.com/q/67217/65808
– Sylvain Leroux
Feb 11 at 12:51
add a comment |
Thanks for such a rapid answer, Steffen. Could you elaborate on this though: "If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash." Why a cryptographic hash still decreases, even slightly, the entropy if the hash size in the same as the input size?
– Sylvain Leroux
Feb 10 at 16:50
5
@SylvainLeroux: A cryptographic hash is not designed as a bijective mapping from N bit input to N bit output. This means that there will be some collision and thus the randomness will be slightly reduced.
– Steffen Ullrich
Feb 10 at 17:04
12
@SylvainLeroux You cannot be sure that all possible 128-bit inputs have different hashes, and they probably don’t. If it is so, then, after the hash, some 128-bit outputs are impossible and others have a higher occurrence than $1 over 2^128$.
– user2233709
Feb 10 at 17:05
Thanks for the clarification Steffen & @user2233709
– Sylvain Leroux
Feb 10 at 17:27
2
FWIW, I've got an estimate of the entropy loss here: crypto.stackexchange.com/q/67217/65808
– Sylvain Leroux
Feb 11 at 12:51
Thanks for such a rapid answer, Steffen. Could you elaborate on this though: "If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash." Why a cryptographic hash still decreases, even slightly, the entropy if the hash size in the same as the input size?
– Sylvain Leroux
Feb 10 at 16:50
Thanks for such a rapid answer, Steffen. Could you elaborate on this though: "If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash." Why a cryptographic hash still decreases, even slightly, the entropy if the hash size in the same as the input size?
– Sylvain Leroux
Feb 10 at 16:50
5
5
@SylvainLeroux: A cryptographic hash is not designed as a bijective mapping from N bit input to N bit output. This means that there will be some collision and thus the randomness will be slightly reduced.
– Steffen Ullrich
Feb 10 at 17:04
@SylvainLeroux: A cryptographic hash is not designed as a bijective mapping from N bit input to N bit output. This means that there will be some collision and thus the randomness will be slightly reduced.
– Steffen Ullrich
Feb 10 at 17:04
12
12
@SylvainLeroux You cannot be sure that all possible 128-bit inputs have different hashes, and they probably don’t. If it is so, then, after the hash, some 128-bit outputs are impossible and others have a higher occurrence than $1 over 2^128$.
– user2233709
Feb 10 at 17:05
@SylvainLeroux You cannot be sure that all possible 128-bit inputs have different hashes, and they probably don’t. If it is so, then, after the hash, some 128-bit outputs are impossible and others have a higher occurrence than $1 over 2^128$.
– user2233709
Feb 10 at 17:05
Thanks for the clarification Steffen & @user2233709
– Sylvain Leroux
Feb 10 at 17:27
Thanks for the clarification Steffen & @user2233709
– Sylvain Leroux
Feb 10 at 17:27
2
2
FWIW, I've got an estimate of the entropy loss here: crypto.stackexchange.com/q/67217/65808
– Sylvain Leroux
Feb 11 at 12:51
FWIW, I've got an estimate of the entropy loss here: crypto.stackexchange.com/q/67217/65808
– Sylvain Leroux
Feb 11 at 12:51
add a comment |
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
This is guaranteed to lose some entropy, but not much. The difficulty in attacking MD5 doesn't directly suggest the amount of loss, but merely tells us it is not zero.
If I fall back on naïve construction, I find that the entropy loss is can be computed from the fixed point probability of 63.21%. which in turn implies that less than one bit of entropy has been lost. I forget how much it is said you actually need, but I know 122 bits of true entropy is plenty.
On the other hand, what are you trying to accomplish here? dd if=/dev/urandom bs=16 count=1 is plenty by itself. There is no point in trying to use md5 in defending kekkak-f against weakness.
If you really feel the need to do something here, make a 128 bit application secret key, generate it in install time directly from /dev/random (not urandom), and xor it into the feed from /dev/urandom. But I don't see a single reason to lift a finger to do this.
answered Feb 11 at 2:42
JoshuaJoshua
72748
3
I think the md5sum was meant as a lazy way to get your 128 bits of randomness formatted as a hex string, without having to look up the syntax ofod.
– Nate Eldredge
Feb 11 at 4:13
@NateEldredge I suspect this was the intent of the sysadmin that wrote the code. The question was raised here, but from the various answers I've got, I doubt this was a deliberate attempt to weaken the key.
– Sylvain Leroux
Feb 11 at 12:48
add a comment |
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
This is guaranteed to lose some entropy, but not much. The difficulty in attacking MD5 doesn't directly suggest the amount of loss, but merely tells us it is not zero.
If I fall back on naïve construction, I find that the entropy loss is can be computed from the fixed point probability of 63.21%. which in turn implies that less than one bit of entropy has been lost. I forget how much it is said you actually need, but I know 122 bits of true entropy is plenty.
On the other hand, what are you trying to accomplish here? dd if=/dev/urandom bs=16 count=1 is plenty by itself. There is no point in trying to use md5 in defending kekkak-f against weakness.
If you really feel the need to do something here, make a 128 bit application secret key, generate it in install time directly from /dev/random (not urandom), and xor it into the feed from /dev/urandom. But I don't see a single reason to lift a finger to do this.
answered Feb 11 at 2:42
JoshuaJoshua
72748
3
I think the md5sum was meant as a lazy way to get your 128 bits of randomness formatted as a hex string, without having to look up the syntax ofod.
– Nate Eldredge
Feb 11 at 4:13
@NateEldredge I suspect this was the intent of the sysadmin that wrote the code. The question was raised here, but from the various answers I've got, I doubt this was a deliberate attempt to weaken the key.
– Sylvain Leroux
Feb 11 at 12:48
add a comment |
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
This is guaranteed to lose some entropy, but not much. The difficulty in attacking MD5 doesn't directly suggest the amount of loss, but merely tells us it is not zero.
If I fall back on naïve construction, I find that the entropy loss is can be computed from the fixed point probability of 63.21%. which in turn implies that less than one bit of entropy has been lost. I forget how much it is said you actually need, but I know 122 bits of true entropy is plenty.
On the other hand, what are you trying to accomplish here? dd if=/dev/urandom bs=16 count=1 is plenty by itself. There is no point in trying to use md5 in defending kekkak-f against weakness.
If you really feel the need to do something here, make a 128 bit application secret key, generate it in install time directly from /dev/random (not urandom), and xor it into the feed from /dev/urandom. But I don't see a single reason to lift a finger to do this.
answered Feb 11 at 2:42
JoshuaJoshua
72748
dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum
This is guaranteed to lose some entropy, but not much. The difficulty in attacking MD5 doesn't directly suggest the amount of loss, but merely tells us it is not zero.
If I fall back on naïve construction, I find that the entropy loss is can be computed from the fixed point probability of 63.21%. which in turn implies that less than one bit of entropy has been lost. I forget how much it is said you actually need, but I know 122 bits of true entropy is plenty.
On the other hand, what are you trying to accomplish here? dd if=/dev/urandom bs=16 count=1 is plenty by itself. There is no point in trying to use md5 in defending kekkak-f against weakness.
If you really feel the need to do something here, make a 128 bit application secret key, generate it in install time directly from /dev/random (not urandom), and xor it into the feed from /dev/urandom. But I don't see a single reason to lift a finger to do this.
answered Feb 11 at 2:42
JoshuaJoshua
72748
answered Feb 11 at 2:42
JoshuaJoshua
72748
answered Feb 11 at 2:42
JoshuaJoshua
72748
answered Feb 11 at 2:42
JoshuaJoshua
72748
72748
3
I think the md5sum was meant as a lazy way to get your 128 bits of randomness formatted as a hex string, without having to look up the syntax ofod.
– Nate Eldredge
Feb 11 at 4:13
@NateEldredge I suspect this was the intent of the sysadmin that wrote the code. The question was raised here, but from the various answers I've got, I doubt this was a deliberate attempt to weaken the key.
– Sylvain Leroux
Feb 11 at 12:48
add a comment |
3
I think the md5sum was meant as a lazy way to get your 128 bits of randomness formatted as a hex string, without having to look up the syntax ofod.
– Nate Eldredge
Feb 11 at 4:13
@NateEldredge I suspect this was the intent of the sysadmin that wrote the code. The question was raised here, but from the various answers I've got, I doubt this was a deliberate attempt to weaken the key.
– Sylvain Leroux
Feb 11 at 12:48
3
3
I think the md5sum was meant as a lazy way to get your 128 bits of randomness formatted as a hex string, without having to look up the syntax of
od.– Nate Eldredge
Feb 11 at 4:13
I think the md5sum was meant as a lazy way to get your 128 bits of randomness formatted as a hex string, without having to look up the syntax of
od.– Nate Eldredge
Feb 11 at 4:13
@NateEldredge I suspect this was the intent of the sysadmin that wrote the code. The question was raised here, but from the various answers I've got, I doubt this was a deliberate attempt to weaken the key.
– Sylvain Leroux
Feb 11 at 12:48
@NateEldredge I suspect this was the intent of the sysadmin that wrote the code. The question was raised here, but from the various answers I've got, I doubt this was a deliberate attempt to weaken the key.
– Sylvain Leroux
Feb 11 at 12:48
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f203318%2fis-there-a-loss-of-entropy-by-hashing-an-n-bit-random-key-to-produce-an-n-bit-ha%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
