Is there a loss of entropy by hashing an N-bit random key to produce an N-bit hash?












4















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







share|improve this question





























    4















    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







    share|improve this question



























      4












      4








      4


      1






      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







      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 3 hours ago







      Sylvain Leroux

















      asked 11 hours ago









      Sylvain LerouxSylvain Leroux

      1387




      1387






















          2 Answers
          2






          active

          oldest

          votes


















          9














          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.






          share|improve this answer
























          • 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
            10 hours ago








          • 3





            @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
            10 hours ago






          • 8





            @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
            10 hours ago











          • Thanks for the clarification Steffen & @user2233709

            – Sylvain Leroux
            10 hours ago





















          1














          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.






          share|improve this answer























            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
            });


            }
            });














            draft saved

            draft discarded


















            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









            9














            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.






            share|improve this answer
























            • 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
              10 hours ago








            • 3





              @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
              10 hours ago






            • 8





              @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
              10 hours ago











            • Thanks for the clarification Steffen & @user2233709

              – Sylvain Leroux
              10 hours ago


















            9














            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.






            share|improve this answer
























            • 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
              10 hours ago








            • 3





              @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
              10 hours ago






            • 8





              @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
              10 hours ago











            • Thanks for the clarification Steffen & @user2233709

              – Sylvain Leroux
              10 hours ago
















            9












            9








            9







            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered 11 hours ago









            Steffen UllrichSteffen Ullrich

            116k13201266




            116k13201266













            • 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
              10 hours ago








            • 3





              @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
              10 hours ago






            • 8





              @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
              10 hours ago











            • Thanks for the clarification Steffen & @user2233709

              – Sylvain Leroux
              10 hours ago





















            • 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
              10 hours ago








            • 3





              @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
              10 hours ago






            • 8





              @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
              10 hours ago











            • Thanks for the clarification Steffen & @user2233709

              – Sylvain Leroux
              10 hours ago



















            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
            10 hours ago







            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
            10 hours ago






            3




            3





            @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
            10 hours ago





            @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
            10 hours ago




            8




            8





            @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
            10 hours ago





            @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
            10 hours ago













            Thanks for the clarification Steffen & @user2233709

            – Sylvain Leroux
            10 hours ago







            Thanks for the clarification Steffen & @user2233709

            – Sylvain Leroux
            10 hours ago















            1














            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.






            share|improve this answer




























              1














              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.






              share|improve this answer


























                1












                1








                1







                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.






                share|improve this answer













                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 1 hour ago









                JoshuaJoshua

                61747




                61747






























                    draft saved

                    draft discarded




















































                    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.




                    draft saved


                    draft discarded














                    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





















































                    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







                    -

                    Popular posts from this blog

                    How to label and detect the document text images

                    Image
                    1 $begingroup$ This is what I mean as document text image: I want to label the texts in image as separate blocks and my model should detect these labels as classes. NOTE: This is how the end result should be like: The labels like Block 1, Block 2, Block 3,.. should be Logo, Title, Date,.. Others, etc. Work done: First approach : I tried to implement this method via Object Detection, it didn't work. It didn't even detect any text. Second approach : Then I tried it using PixelLink. As this model is build for scene text detection, it detected each and every text in the image. But this method can detect multiple lines of text if the threshold values are increased. But I have no idea how do I add labels to the text blocks. PIXEL_CLS_WEIGHT_all_ones = 'PIXEL_CLS_WEIGHT_all_ones' PIXEL_C...
                    Read more

                    Vallis Paradisi

                    Image
                    Coordinata: .mw-parser-output .geo-default,.mw-parser-output .geo-dms,.mw-parser-output .geo-dec{display:inline}.mw-parser-output .geo-nondefault,.mw-parser-output .geo-multi-punct{display:none}.mw-parser-output .longitude,.mw-parser-output .latitude{white-space:nowrap} 33°03′S 71°37′W  /  33.05°S 71.617°W  / -33.05; -71.617 Vallis Paradisi Res apud Vicidata repertae: Civitas : Chilia Numerus incolarum : 296 655 Zona horaria : UTC-4 Situs interretialis Nomen officiale : Valparaíso Gubernium Consilium : municipal council of Valparaíso Geographia Superficies : 401 600 000 Metrum quadratum Coniunctiones urbium Urbes gemellae : Ovetum , Badalona , Santa Fe , Ora longa , Sciamhaevum , Quantunia , Callao , Bat Yam , Melaka , Novorossiysk , Busan , Corduba , Odessa , Rosario , Malacca , Barcino , Soteropolis , Franciscopolis (California) , Guanajuato, Silao Tabula aut despectus Despectus in portum sinumque et urbem Vallis Paradisi Vallis Para...
                    Read more

                    Tabula Rosettana

                    Image
                    Tabula multilinguis Rosettana in Museo Britannico ostenditur. Tabula Rosettana, [1] etiam titulo OGIS 90 agnita, est stela decreto de rebus sacris in Aegypto anno 196 a.C.n. lato inscripta. Tabula iuxta Rosettam Aegypti, urbem in delta Nili et ad oram maris Mediterranei iacentem, anno 1799 a milite Francico reperta est. Inventio stelae, linguis duabus scripturisque tribus inscriptae, eruditis Instituti Aegypti statim nuntiata est; ibi enim iussu imperatoris Napoleonis eruditi omnium scientiarum (sub aegide Commissionis Scientiarum et Artium) properaverant cum expeditione Francica. Qua a Britannis mox debellata, tabula Rosettana Londinium missa hodie apud Museum Britannicum iacet. Textus Graecus cito lectus interpretationi textuum Aegyptiorum (in formis hieroglyphica et demotica expressorum) gradatim adiuvit. Denique textum plene interpretatus est Ioannes Franciscus Champollion. Ab opere eruditorum cumulativo coepit hodiernus scripturae hieroglyphicae linguaeque Aegyptiae a...
                    Read more