Does TLS 1.2 have cipher suite specific algorithms/behavior for VerifyData?










0















I am working on a Golang implementation of DTLS, and I am not able to generate a valid value for VerifyData. I have a working example here this shows my code (and how I get something different then OpenSSL)



printf debugging OpenSSL it looks like the hash of handshake bodies is different then mine. It seems really unlikely, I would assume that I am collecting packets wrong. But putting printf statements before the



The cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and you can see the entire codebase at https://github.com/pions/dtls










share|improve this question













migrated from security.stackexchange.com Nov 13 '18 at 3:45


This question came from our site for information security professionals.






















    0















    I am working on a Golang implementation of DTLS, and I am not able to generate a valid value for VerifyData. I have a working example here this shows my code (and how I get something different then OpenSSL)



    printf debugging OpenSSL it looks like the hash of handshake bodies is different then mine. It seems really unlikely, I would assume that I am collecting packets wrong. But putting printf statements before the



    The cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and you can see the entire codebase at https://github.com/pions/dtls










    share|improve this question













    migrated from security.stackexchange.com Nov 13 '18 at 3:45


    This question came from our site for information security professionals.




















      0












      0








      0








      I am working on a Golang implementation of DTLS, and I am not able to generate a valid value for VerifyData. I have a working example here this shows my code (and how I get something different then OpenSSL)



      printf debugging OpenSSL it looks like the hash of handshake bodies is different then mine. It seems really unlikely, I would assume that I am collecting packets wrong. But putting printf statements before the



      The cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and you can see the entire codebase at https://github.com/pions/dtls










      share|improve this question














      I am working on a Golang implementation of DTLS, and I am not able to generate a valid value for VerifyData. I have a working example here this shows my code (and how I get something different then OpenSSL)



      printf debugging OpenSSL it looks like the hash of handshake bodies is different then mine. It seems really unlikely, I would assume that I am collecting packets wrong. But putting printf statements before the



      The cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and you can see the entire codebase at https://github.com/pions/dtls







      ssl openssl






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 12 '18 at 9:31









      Sean DuBoisSean DuBois

      1048




      1048




      migrated from security.stackexchange.com Nov 13 '18 at 3:45


      This question came from our site for information security professionals.









      migrated from security.stackexchange.com Nov 13 '18 at 3:45


      This question came from our site for information security professionals.
























          1 Answer
          1






          active

          oldest

          votes


















          1














          VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.



          However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.






          share|improve this answer
























            Your Answer






            StackExchange.ifUsing("editor", function ()
            StackExchange.using("externalEditor", function ()
            StackExchange.using("snippets", function ()
            StackExchange.snippets.init();
            );
            );
            , "code-snippets");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "1"
            ;
            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: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            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
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53273484%2fdoes-tls-1-2-have-cipher-suite-specific-algorithms-behavior-for-verifydata%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            1














            VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.



            However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.






            share|improve this answer





























              1














              VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.



              However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.






              share|improve this answer



























                1












                1








                1







                VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.



                However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.






                share|improve this answer















                VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.



                However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Nov 13 '18 at 9:27

























                answered Nov 13 '18 at 9:09









                dave_thompson_085dave_thompson_085

                13.2k11632




                13.2k11632



























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Stack Overflow!


                    • 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%2fstackoverflow.com%2fquestions%2f53273484%2fdoes-tls-1-2-have-cipher-suite-specific-algorithms-behavior-for-verifydata%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

                    Use pre created SQLite database for Android project in kotlin

                    Darth Vader #20

                    Ondo