Need a test suite for my RSA implementation











up vote
5
down vote

favorite
1












I have an assignment to build a software which can encrypt/decrypt by RSA method. I already did it, but my teacher said that I need to find a test suite (include: modulus, public key, private key) to test if my software runs correctly.



He needs real data which has already been tested by someone else and that data needs to be mentioned in lectures, books, reports, benchmarks, etc...



I tried to find them but I cannot :(. I'm very appreciated if you can help me.
Thank you.










share|improve this question




























    up vote
    5
    down vote

    favorite
    1












    I have an assignment to build a software which can encrypt/decrypt by RSA method. I already did it, but my teacher said that I need to find a test suite (include: modulus, public key, private key) to test if my software runs correctly.



    He needs real data which has already been tested by someone else and that data needs to be mentioned in lectures, books, reports, benchmarks, etc...



    I tried to find them but I cannot :(. I'm very appreciated if you can help me.
    Thank you.










    share|improve this question


























      up vote
      5
      down vote

      favorite
      1









      up vote
      5
      down vote

      favorite
      1






      1





      I have an assignment to build a software which can encrypt/decrypt by RSA method. I already did it, but my teacher said that I need to find a test suite (include: modulus, public key, private key) to test if my software runs correctly.



      He needs real data which has already been tested by someone else and that data needs to be mentioned in lectures, books, reports, benchmarks, etc...



      I tried to find them but I cannot :(. I'm very appreciated if you can help me.
      Thank you.










      share|improve this question















      I have an assignment to build a software which can encrypt/decrypt by RSA method. I already did it, but my teacher said that I need to find a test suite (include: modulus, public key, private key) to test if my software runs correctly.



      He needs real data which has already been tested by someone else and that data needs to be mentioned in lectures, books, reports, benchmarks, etc...



      I tried to find them but I cannot :(. I'm very appreciated if you can help me.
      Thank you.







      rsa test-vectors






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 12 at 1:58









      kiwidrew

      3739




      3739










      asked Nov 11 at 12:41









      user63361

      311




      311






















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          7
          down vote













          There are RSA keys pairs in the validation suite for the RSA part of FIPS 186-4 (see second part of this answer for details).



          Because "encrypt/decrypt by RSA method" is not well-defined (for lack of indication of the padding method), there's no way to tell which Known Answer Test vectors for it fit the question's need.



          Also, only the decryption code can be tested with fixed KAT: RSA encryption with proper random padding is not deterministic, thus its code needs to be modified (de-randomized) for testing against KAT.





          FIPS 186-4 is a standard for digital signatures per a variety of methods, including several RSA-based. It has a test suite, with at the bottom of the page links to files with test vectors. The one for FIPS 186-4 RSA-based functions is 186-3rsatestvectors.zip. It contains several keys pairs. For example, SigGenPSS_186-3.txt starts with



          [mod = 2048]

          n = c5062b58d8539c765e1e5dbaf14cf75dd56c2e13105fecfd1a930bbb5948ff328f126abe779359ca59bca752c308d281573bc6178b6c0fef7dc445e4f826430437b9f9d790581de5749c2cb9cb26d42b2fee15b6b26f09c99670336423b86bc5bec71113157be2d944d7ff3eebffb28413143ea36755db0ae62ff5b724eecb3d316b6bac67e89cacd8171937e2ab19bd353a89acea8c36f81c89a620d5fd2effea896601c7f9daca7f033f635a3a943331d1b1b4f5288790b53af352f1121ca1bef205f40dc012c412b40bdd27585b946466d75f7ee0a7f9d549b4bece6f43ac3ee65fe7fd37123359d9f1a850ad450aaf5c94eb11dea3fc0fc6e9856b1805ef

          e = 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000086c94f
          d = 49e5786bb4d332f94586327bde088875379b75d128488f08e574ab4715302a87eea52d4c4a23d8b97af7944804337c5f55e16ba9ffafc0c9fd9b88eca443f39b7967170ddb8ce7ddb93c6087c8066c4a95538a441b9dc80dc9f7810054fd1e5c9d0250c978bb2d748abe1e9465d71a8165d3126dce5db2adacc003e9062ba37a54b63e5f49a4eafebd7e4bf5b0a796c2b3a950fa09c798d3fa3e86c4b62c33ba9365eda054e5fe74a41f21b595026acf1093c90a8c71722f91af1ed29a41a2449a320fc7ba3120e3e8c3e4240c04925cc698ecd66c7c906bdf240adad972b4dff4869d400b5d13e33eeba38e075e872b0ed3e91cc9c283867a4ffc3901d2069f


          Note: $mathtt{mod}$ is the bit size of the public modulus, expressed in decimal. $mathtt n$, $mathtt e$ and $mathtt d$ are the public modulus, the public exponent, and the FIPS 186-4-mandated private exponent, expressed in hexadecimal. Therefore, $mathtt d$ was obtained as $mathtt e^{-1}bmodlambda(mathtt n)$ (where $lambda$ is Carmichael's function), but is usable just as $mathtt e^{-1}bmodvarphi(mathtt n)$ would be (where $varphi$ is Euler's totient), another common private exponent in RSA.






          share|improve this answer























          • Thank you so much :) That is all what I need
            – user63361
            Nov 11 at 14:01


















          up vote
          0
          down vote













          For the modulus $n=pq$ you need to verify that $p$ and $q$ are prime numbers. You can do this with a probabilistic primality test like Rabin-Miller.
          For the public key $e$ you need to verify that it is coprime to the euler totient $phi (n)$ you can do this with the extended Euclidean algorithm.
          For the private key $d$ you need to verify that $de equiv 1 pmod n$. You can do this with the extended Euclidean algorithm.






          share|improve this answer





















          • .First of all, I want to say thank you. I already did all of what you say (my software runs well I can say that), at this time the things that I need is some data are mentioned in lectures, books, reports, benchmarks,.... to test it (because my teacher doesn't accept any data that is generated randomly)
            – user63361
            Nov 11 at 13:20










          • Ok what you need is a test vector suite. You can use NIST vectors available here: csrc.nist.gov/Projects/…
            – Youssef El Housni
            Nov 11 at 13:30






          • 2




            $de equiv 1 pmod n$ usually does not hold. $d,eequiv 1 pmod{lambda (n)}$ holds. $d,eequiv 1 pmod{phi (n)}$ holds for some variants of RSA key generation. Verification of $d$ is usually performed by computing $d,ebmod{lambda (n)}=1$ when the factorization of $n$ is known, including derived from $(n,e,d)$; or checking that $x^{e,d}bmod n=x$ for a few $xin[2,n-2]$, otherwise.
            – fgrieu
            Nov 11 at 14:38




















          up vote
          0
          down vote













          The most common way to generate test data for a cryptography algorithm is to use another implementation of this algorithm that you trust. This lets you generate as much test data as you like, with whatever key size, message size, etc. that you desire.



          This is the way cryptography implementations are functionally validated in the real world. Sometimes it's done by using a known-good implementation, generating test data, and checking that the new implementation generates the same results. Sometimes it's done by running two or more implementations in parallel on the same inputs and checking that they generate the same results.



          How, you may ask, was the very first implementation validated? It depends. Usually the very first implementation is written in the most straightforward manner possible. No optimizations, no side channel resistance and other complications. Then people carefully review it against the English or mathematical description of the algorithm. Then someone else independently writes their own implementation and compares the results with the first.



          Most specifications of cryptographic algorithms contain a few sample inputs and outputs. In cryptography, these are called “test vectors”. NIST CAVP has longer lists of test vectors for algorithms that NIST approves of. Given the nature of cryptographic calculations, just getting one test vector right is usually enough to show that your implementation is basically correct in the nominal case, at least for the given key size and message size. But it isn't enough to have a lot of confidence in your code. You should at least test some different key sizes and message sizes. Usually the only way to obtain sufficient test data is by running one or more known-good implementation.



          As an added difficulty, some algorithms are randomized, for example RSA-PSS signature and any form of encryption. To use test vectors, you need to be able to configure your implementation to use a “fake” random stream that is identical to the random stream used to generate the test vectors. To compare with another implementation, the two implementations need to use the same random stream. This isn't always possible. If you can't do that, you can make interoperability tests. For example, encrypt with one implementation and decrypt with another implementation.



          OpenSSL is a popular cryptography library, but it isn't always easy to use. Cryptodome is a Python library that I find convenient to generate test vectors.






          share|improve this answer





















            Your Answer





            StackExchange.ifUsing("editor", function () {
            return StackExchange.using("mathjaxEditing", function () {
            StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
            StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
            });
            });
            }, "mathjax-editing");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "281"
            };
            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',
            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%2fcrypto.stackexchange.com%2fquestions%2f63874%2fneed-a-test-suite-for-my-rsa-implementation%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            7
            down vote













            There are RSA keys pairs in the validation suite for the RSA part of FIPS 186-4 (see second part of this answer for details).



            Because "encrypt/decrypt by RSA method" is not well-defined (for lack of indication of the padding method), there's no way to tell which Known Answer Test vectors for it fit the question's need.



            Also, only the decryption code can be tested with fixed KAT: RSA encryption with proper random padding is not deterministic, thus its code needs to be modified (de-randomized) for testing against KAT.





            FIPS 186-4 is a standard for digital signatures per a variety of methods, including several RSA-based. It has a test suite, with at the bottom of the page links to files with test vectors. The one for FIPS 186-4 RSA-based functions is 186-3rsatestvectors.zip. It contains several keys pairs. For example, SigGenPSS_186-3.txt starts with



            [mod = 2048]

            n = c5062b58d8539c765e1e5dbaf14cf75dd56c2e13105fecfd1a930bbb5948ff328f126abe779359ca59bca752c308d281573bc6178b6c0fef7dc445e4f826430437b9f9d790581de5749c2cb9cb26d42b2fee15b6b26f09c99670336423b86bc5bec71113157be2d944d7ff3eebffb28413143ea36755db0ae62ff5b724eecb3d316b6bac67e89cacd8171937e2ab19bd353a89acea8c36f81c89a620d5fd2effea896601c7f9daca7f033f635a3a943331d1b1b4f5288790b53af352f1121ca1bef205f40dc012c412b40bdd27585b946466d75f7ee0a7f9d549b4bece6f43ac3ee65fe7fd37123359d9f1a850ad450aaf5c94eb11dea3fc0fc6e9856b1805ef

            e = 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000086c94f
            d = 49e5786bb4d332f94586327bde088875379b75d128488f08e574ab4715302a87eea52d4c4a23d8b97af7944804337c5f55e16ba9ffafc0c9fd9b88eca443f39b7967170ddb8ce7ddb93c6087c8066c4a95538a441b9dc80dc9f7810054fd1e5c9d0250c978bb2d748abe1e9465d71a8165d3126dce5db2adacc003e9062ba37a54b63e5f49a4eafebd7e4bf5b0a796c2b3a950fa09c798d3fa3e86c4b62c33ba9365eda054e5fe74a41f21b595026acf1093c90a8c71722f91af1ed29a41a2449a320fc7ba3120e3e8c3e4240c04925cc698ecd66c7c906bdf240adad972b4dff4869d400b5d13e33eeba38e075e872b0ed3e91cc9c283867a4ffc3901d2069f


            Note: $mathtt{mod}$ is the bit size of the public modulus, expressed in decimal. $mathtt n$, $mathtt e$ and $mathtt d$ are the public modulus, the public exponent, and the FIPS 186-4-mandated private exponent, expressed in hexadecimal. Therefore, $mathtt d$ was obtained as $mathtt e^{-1}bmodlambda(mathtt n)$ (where $lambda$ is Carmichael's function), but is usable just as $mathtt e^{-1}bmodvarphi(mathtt n)$ would be (where $varphi$ is Euler's totient), another common private exponent in RSA.






            share|improve this answer























            • Thank you so much :) That is all what I need
              – user63361
              Nov 11 at 14:01















            up vote
            7
            down vote













            There are RSA keys pairs in the validation suite for the RSA part of FIPS 186-4 (see second part of this answer for details).



            Because "encrypt/decrypt by RSA method" is not well-defined (for lack of indication of the padding method), there's no way to tell which Known Answer Test vectors for it fit the question's need.



            Also, only the decryption code can be tested with fixed KAT: RSA encryption with proper random padding is not deterministic, thus its code needs to be modified (de-randomized) for testing against KAT.





            FIPS 186-4 is a standard for digital signatures per a variety of methods, including several RSA-based. It has a test suite, with at the bottom of the page links to files with test vectors. The one for FIPS 186-4 RSA-based functions is 186-3rsatestvectors.zip. It contains several keys pairs. For example, SigGenPSS_186-3.txt starts with



            [mod = 2048]

            n = c5062b58d8539c765e1e5dbaf14cf75dd56c2e13105fecfd1a930bbb5948ff328f126abe779359ca59bca752c308d281573bc6178b6c0fef7dc445e4f826430437b9f9d790581de5749c2cb9cb26d42b2fee15b6b26f09c99670336423b86bc5bec71113157be2d944d7ff3eebffb28413143ea36755db0ae62ff5b724eecb3d316b6bac67e89cacd8171937e2ab19bd353a89acea8c36f81c89a620d5fd2effea896601c7f9daca7f033f635a3a943331d1b1b4f5288790b53af352f1121ca1bef205f40dc012c412b40bdd27585b946466d75f7ee0a7f9d549b4bece6f43ac3ee65fe7fd37123359d9f1a850ad450aaf5c94eb11dea3fc0fc6e9856b1805ef

            e = 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000086c94f
            d = 49e5786bb4d332f94586327bde088875379b75d128488f08e574ab4715302a87eea52d4c4a23d8b97af7944804337c5f55e16ba9ffafc0c9fd9b88eca443f39b7967170ddb8ce7ddb93c6087c8066c4a95538a441b9dc80dc9f7810054fd1e5c9d0250c978bb2d748abe1e9465d71a8165d3126dce5db2adacc003e9062ba37a54b63e5f49a4eafebd7e4bf5b0a796c2b3a950fa09c798d3fa3e86c4b62c33ba9365eda054e5fe74a41f21b595026acf1093c90a8c71722f91af1ed29a41a2449a320fc7ba3120e3e8c3e4240c04925cc698ecd66c7c906bdf240adad972b4dff4869d400b5d13e33eeba38e075e872b0ed3e91cc9c283867a4ffc3901d2069f


            Note: $mathtt{mod}$ is the bit size of the public modulus, expressed in decimal. $mathtt n$, $mathtt e$ and $mathtt d$ are the public modulus, the public exponent, and the FIPS 186-4-mandated private exponent, expressed in hexadecimal. Therefore, $mathtt d$ was obtained as $mathtt e^{-1}bmodlambda(mathtt n)$ (where $lambda$ is Carmichael's function), but is usable just as $mathtt e^{-1}bmodvarphi(mathtt n)$ would be (where $varphi$ is Euler's totient), another common private exponent in RSA.






            share|improve this answer























            • Thank you so much :) That is all what I need
              – user63361
              Nov 11 at 14:01













            up vote
            7
            down vote










            up vote
            7
            down vote









            There are RSA keys pairs in the validation suite for the RSA part of FIPS 186-4 (see second part of this answer for details).



            Because "encrypt/decrypt by RSA method" is not well-defined (for lack of indication of the padding method), there's no way to tell which Known Answer Test vectors for it fit the question's need.



            Also, only the decryption code can be tested with fixed KAT: RSA encryption with proper random padding is not deterministic, thus its code needs to be modified (de-randomized) for testing against KAT.





            FIPS 186-4 is a standard for digital signatures per a variety of methods, including several RSA-based. It has a test suite, with at the bottom of the page links to files with test vectors. The one for FIPS 186-4 RSA-based functions is 186-3rsatestvectors.zip. It contains several keys pairs. For example, SigGenPSS_186-3.txt starts with



            [mod = 2048]

            n = c5062b58d8539c765e1e5dbaf14cf75dd56c2e13105fecfd1a930bbb5948ff328f126abe779359ca59bca752c308d281573bc6178b6c0fef7dc445e4f826430437b9f9d790581de5749c2cb9cb26d42b2fee15b6b26f09c99670336423b86bc5bec71113157be2d944d7ff3eebffb28413143ea36755db0ae62ff5b724eecb3d316b6bac67e89cacd8171937e2ab19bd353a89acea8c36f81c89a620d5fd2effea896601c7f9daca7f033f635a3a943331d1b1b4f5288790b53af352f1121ca1bef205f40dc012c412b40bdd27585b946466d75f7ee0a7f9d549b4bece6f43ac3ee65fe7fd37123359d9f1a850ad450aaf5c94eb11dea3fc0fc6e9856b1805ef

            e = 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000086c94f
            d = 49e5786bb4d332f94586327bde088875379b75d128488f08e574ab4715302a87eea52d4c4a23d8b97af7944804337c5f55e16ba9ffafc0c9fd9b88eca443f39b7967170ddb8ce7ddb93c6087c8066c4a95538a441b9dc80dc9f7810054fd1e5c9d0250c978bb2d748abe1e9465d71a8165d3126dce5db2adacc003e9062ba37a54b63e5f49a4eafebd7e4bf5b0a796c2b3a950fa09c798d3fa3e86c4b62c33ba9365eda054e5fe74a41f21b595026acf1093c90a8c71722f91af1ed29a41a2449a320fc7ba3120e3e8c3e4240c04925cc698ecd66c7c906bdf240adad972b4dff4869d400b5d13e33eeba38e075e872b0ed3e91cc9c283867a4ffc3901d2069f


            Note: $mathtt{mod}$ is the bit size of the public modulus, expressed in decimal. $mathtt n$, $mathtt e$ and $mathtt d$ are the public modulus, the public exponent, and the FIPS 186-4-mandated private exponent, expressed in hexadecimal. Therefore, $mathtt d$ was obtained as $mathtt e^{-1}bmodlambda(mathtt n)$ (where $lambda$ is Carmichael's function), but is usable just as $mathtt e^{-1}bmodvarphi(mathtt n)$ would be (where $varphi$ is Euler's totient), another common private exponent in RSA.






            share|improve this answer














            There are RSA keys pairs in the validation suite for the RSA part of FIPS 186-4 (see second part of this answer for details).



            Because "encrypt/decrypt by RSA method" is not well-defined (for lack of indication of the padding method), there's no way to tell which Known Answer Test vectors for it fit the question's need.



            Also, only the decryption code can be tested with fixed KAT: RSA encryption with proper random padding is not deterministic, thus its code needs to be modified (de-randomized) for testing against KAT.





            FIPS 186-4 is a standard for digital signatures per a variety of methods, including several RSA-based. It has a test suite, with at the bottom of the page links to files with test vectors. The one for FIPS 186-4 RSA-based functions is 186-3rsatestvectors.zip. It contains several keys pairs. For example, SigGenPSS_186-3.txt starts with



            [mod = 2048]

            n = c5062b58d8539c765e1e5dbaf14cf75dd56c2e13105fecfd1a930bbb5948ff328f126abe779359ca59bca752c308d281573bc6178b6c0fef7dc445e4f826430437b9f9d790581de5749c2cb9cb26d42b2fee15b6b26f09c99670336423b86bc5bec71113157be2d944d7ff3eebffb28413143ea36755db0ae62ff5b724eecb3d316b6bac67e89cacd8171937e2ab19bd353a89acea8c36f81c89a620d5fd2effea896601c7f9daca7f033f635a3a943331d1b1b4f5288790b53af352f1121ca1bef205f40dc012c412b40bdd27585b946466d75f7ee0a7f9d549b4bece6f43ac3ee65fe7fd37123359d9f1a850ad450aaf5c94eb11dea3fc0fc6e9856b1805ef

            e = 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000086c94f
            d = 49e5786bb4d332f94586327bde088875379b75d128488f08e574ab4715302a87eea52d4c4a23d8b97af7944804337c5f55e16ba9ffafc0c9fd9b88eca443f39b7967170ddb8ce7ddb93c6087c8066c4a95538a441b9dc80dc9f7810054fd1e5c9d0250c978bb2d748abe1e9465d71a8165d3126dce5db2adacc003e9062ba37a54b63e5f49a4eafebd7e4bf5b0a796c2b3a950fa09c798d3fa3e86c4b62c33ba9365eda054e5fe74a41f21b595026acf1093c90a8c71722f91af1ed29a41a2449a320fc7ba3120e3e8c3e4240c04925cc698ecd66c7c906bdf240adad972b4dff4869d400b5d13e33eeba38e075e872b0ed3e91cc9c283867a4ffc3901d2069f


            Note: $mathtt{mod}$ is the bit size of the public modulus, expressed in decimal. $mathtt n$, $mathtt e$ and $mathtt d$ are the public modulus, the public exponent, and the FIPS 186-4-mandated private exponent, expressed in hexadecimal. Therefore, $mathtt d$ was obtained as $mathtt e^{-1}bmodlambda(mathtt n)$ (where $lambda$ is Carmichael's function), but is usable just as $mathtt e^{-1}bmodvarphi(mathtt n)$ would be (where $varphi$ is Euler's totient), another common private exponent in RSA.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 11 at 14:00

























            answered Nov 11 at 13:33









            fgrieu

            77k7158322




            77k7158322












            • Thank you so much :) That is all what I need
              – user63361
              Nov 11 at 14:01


















            • Thank you so much :) That is all what I need
              – user63361
              Nov 11 at 14:01
















            Thank you so much :) That is all what I need
            – user63361
            Nov 11 at 14:01




            Thank you so much :) That is all what I need
            – user63361
            Nov 11 at 14:01










            up vote
            0
            down vote













            For the modulus $n=pq$ you need to verify that $p$ and $q$ are prime numbers. You can do this with a probabilistic primality test like Rabin-Miller.
            For the public key $e$ you need to verify that it is coprime to the euler totient $phi (n)$ you can do this with the extended Euclidean algorithm.
            For the private key $d$ you need to verify that $de equiv 1 pmod n$. You can do this with the extended Euclidean algorithm.






            share|improve this answer





















            • .First of all, I want to say thank you. I already did all of what you say (my software runs well I can say that), at this time the things that I need is some data are mentioned in lectures, books, reports, benchmarks,.... to test it (because my teacher doesn't accept any data that is generated randomly)
              – user63361
              Nov 11 at 13:20










            • Ok what you need is a test vector suite. You can use NIST vectors available here: csrc.nist.gov/Projects/…
              – Youssef El Housni
              Nov 11 at 13:30






            • 2




              $de equiv 1 pmod n$ usually does not hold. $d,eequiv 1 pmod{lambda (n)}$ holds. $d,eequiv 1 pmod{phi (n)}$ holds for some variants of RSA key generation. Verification of $d$ is usually performed by computing $d,ebmod{lambda (n)}=1$ when the factorization of $n$ is known, including derived from $(n,e,d)$; or checking that $x^{e,d}bmod n=x$ for a few $xin[2,n-2]$, otherwise.
              – fgrieu
              Nov 11 at 14:38

















            up vote
            0
            down vote













            For the modulus $n=pq$ you need to verify that $p$ and $q$ are prime numbers. You can do this with a probabilistic primality test like Rabin-Miller.
            For the public key $e$ you need to verify that it is coprime to the euler totient $phi (n)$ you can do this with the extended Euclidean algorithm.
            For the private key $d$ you need to verify that $de equiv 1 pmod n$. You can do this with the extended Euclidean algorithm.






            share|improve this answer





















            • .First of all, I want to say thank you. I already did all of what you say (my software runs well I can say that), at this time the things that I need is some data are mentioned in lectures, books, reports, benchmarks,.... to test it (because my teacher doesn't accept any data that is generated randomly)
              – user63361
              Nov 11 at 13:20










            • Ok what you need is a test vector suite. You can use NIST vectors available here: csrc.nist.gov/Projects/…
              – Youssef El Housni
              Nov 11 at 13:30






            • 2




              $de equiv 1 pmod n$ usually does not hold. $d,eequiv 1 pmod{lambda (n)}$ holds. $d,eequiv 1 pmod{phi (n)}$ holds for some variants of RSA key generation. Verification of $d$ is usually performed by computing $d,ebmod{lambda (n)}=1$ when the factorization of $n$ is known, including derived from $(n,e,d)$; or checking that $x^{e,d}bmod n=x$ for a few $xin[2,n-2]$, otherwise.
              – fgrieu
              Nov 11 at 14:38















            up vote
            0
            down vote










            up vote
            0
            down vote









            For the modulus $n=pq$ you need to verify that $p$ and $q$ are prime numbers. You can do this with a probabilistic primality test like Rabin-Miller.
            For the public key $e$ you need to verify that it is coprime to the euler totient $phi (n)$ you can do this with the extended Euclidean algorithm.
            For the private key $d$ you need to verify that $de equiv 1 pmod n$. You can do this with the extended Euclidean algorithm.






            share|improve this answer












            For the modulus $n=pq$ you need to verify that $p$ and $q$ are prime numbers. You can do this with a probabilistic primality test like Rabin-Miller.
            For the public key $e$ you need to verify that it is coprime to the euler totient $phi (n)$ you can do this with the extended Euclidean algorithm.
            For the private key $d$ you need to verify that $de equiv 1 pmod n$. You can do this with the extended Euclidean algorithm.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 11 at 13:09









            Youssef El Housni

            3447




            3447












            • .First of all, I want to say thank you. I already did all of what you say (my software runs well I can say that), at this time the things that I need is some data are mentioned in lectures, books, reports, benchmarks,.... to test it (because my teacher doesn't accept any data that is generated randomly)
              – user63361
              Nov 11 at 13:20










            • Ok what you need is a test vector suite. You can use NIST vectors available here: csrc.nist.gov/Projects/…
              – Youssef El Housni
              Nov 11 at 13:30






            • 2




              $de equiv 1 pmod n$ usually does not hold. $d,eequiv 1 pmod{lambda (n)}$ holds. $d,eequiv 1 pmod{phi (n)}$ holds for some variants of RSA key generation. Verification of $d$ is usually performed by computing $d,ebmod{lambda (n)}=1$ when the factorization of $n$ is known, including derived from $(n,e,d)$; or checking that $x^{e,d}bmod n=x$ for a few $xin[2,n-2]$, otherwise.
              – fgrieu
              Nov 11 at 14:38




















            • .First of all, I want to say thank you. I already did all of what you say (my software runs well I can say that), at this time the things that I need is some data are mentioned in lectures, books, reports, benchmarks,.... to test it (because my teacher doesn't accept any data that is generated randomly)
              – user63361
              Nov 11 at 13:20










            • Ok what you need is a test vector suite. You can use NIST vectors available here: csrc.nist.gov/Projects/…
              – Youssef El Housni
              Nov 11 at 13:30






            • 2




              $de equiv 1 pmod n$ usually does not hold. $d,eequiv 1 pmod{lambda (n)}$ holds. $d,eequiv 1 pmod{phi (n)}$ holds for some variants of RSA key generation. Verification of $d$ is usually performed by computing $d,ebmod{lambda (n)}=1$ when the factorization of $n$ is known, including derived from $(n,e,d)$; or checking that $x^{e,d}bmod n=x$ for a few $xin[2,n-2]$, otherwise.
              – fgrieu
              Nov 11 at 14:38


















            .First of all, I want to say thank you. I already did all of what you say (my software runs well I can say that), at this time the things that I need is some data are mentioned in lectures, books, reports, benchmarks,.... to test it (because my teacher doesn't accept any data that is generated randomly)
            – user63361
            Nov 11 at 13:20




            .First of all, I want to say thank you. I already did all of what you say (my software runs well I can say that), at this time the things that I need is some data are mentioned in lectures, books, reports, benchmarks,.... to test it (because my teacher doesn't accept any data that is generated randomly)
            – user63361
            Nov 11 at 13:20












            Ok what you need is a test vector suite. You can use NIST vectors available here: csrc.nist.gov/Projects/…
            – Youssef El Housni
            Nov 11 at 13:30




            Ok what you need is a test vector suite. You can use NIST vectors available here: csrc.nist.gov/Projects/…
            – Youssef El Housni
            Nov 11 at 13:30




            2




            2




            $de equiv 1 pmod n$ usually does not hold. $d,eequiv 1 pmod{lambda (n)}$ holds. $d,eequiv 1 pmod{phi (n)}$ holds for some variants of RSA key generation. Verification of $d$ is usually performed by computing $d,ebmod{lambda (n)}=1$ when the factorization of $n$ is known, including derived from $(n,e,d)$; or checking that $x^{e,d}bmod n=x$ for a few $xin[2,n-2]$, otherwise.
            – fgrieu
            Nov 11 at 14:38






            $de equiv 1 pmod n$ usually does not hold. $d,eequiv 1 pmod{lambda (n)}$ holds. $d,eequiv 1 pmod{phi (n)}$ holds for some variants of RSA key generation. Verification of $d$ is usually performed by computing $d,ebmod{lambda (n)}=1$ when the factorization of $n$ is known, including derived from $(n,e,d)$; or checking that $x^{e,d}bmod n=x$ for a few $xin[2,n-2]$, otherwise.
            – fgrieu
            Nov 11 at 14:38












            up vote
            0
            down vote













            The most common way to generate test data for a cryptography algorithm is to use another implementation of this algorithm that you trust. This lets you generate as much test data as you like, with whatever key size, message size, etc. that you desire.



            This is the way cryptography implementations are functionally validated in the real world. Sometimes it's done by using a known-good implementation, generating test data, and checking that the new implementation generates the same results. Sometimes it's done by running two or more implementations in parallel on the same inputs and checking that they generate the same results.



            How, you may ask, was the very first implementation validated? It depends. Usually the very first implementation is written in the most straightforward manner possible. No optimizations, no side channel resistance and other complications. Then people carefully review it against the English or mathematical description of the algorithm. Then someone else independently writes their own implementation and compares the results with the first.



            Most specifications of cryptographic algorithms contain a few sample inputs and outputs. In cryptography, these are called “test vectors”. NIST CAVP has longer lists of test vectors for algorithms that NIST approves of. Given the nature of cryptographic calculations, just getting one test vector right is usually enough to show that your implementation is basically correct in the nominal case, at least for the given key size and message size. But it isn't enough to have a lot of confidence in your code. You should at least test some different key sizes and message sizes. Usually the only way to obtain sufficient test data is by running one or more known-good implementation.



            As an added difficulty, some algorithms are randomized, for example RSA-PSS signature and any form of encryption. To use test vectors, you need to be able to configure your implementation to use a “fake” random stream that is identical to the random stream used to generate the test vectors. To compare with another implementation, the two implementations need to use the same random stream. This isn't always possible. If you can't do that, you can make interoperability tests. For example, encrypt with one implementation and decrypt with another implementation.



            OpenSSL is a popular cryptography library, but it isn't always easy to use. Cryptodome is a Python library that I find convenient to generate test vectors.






            share|improve this answer

























              up vote
              0
              down vote













              The most common way to generate test data for a cryptography algorithm is to use another implementation of this algorithm that you trust. This lets you generate as much test data as you like, with whatever key size, message size, etc. that you desire.



              This is the way cryptography implementations are functionally validated in the real world. Sometimes it's done by using a known-good implementation, generating test data, and checking that the new implementation generates the same results. Sometimes it's done by running two or more implementations in parallel on the same inputs and checking that they generate the same results.



              How, you may ask, was the very first implementation validated? It depends. Usually the very first implementation is written in the most straightforward manner possible. No optimizations, no side channel resistance and other complications. Then people carefully review it against the English or mathematical description of the algorithm. Then someone else independently writes their own implementation and compares the results with the first.



              Most specifications of cryptographic algorithms contain a few sample inputs and outputs. In cryptography, these are called “test vectors”. NIST CAVP has longer lists of test vectors for algorithms that NIST approves of. Given the nature of cryptographic calculations, just getting one test vector right is usually enough to show that your implementation is basically correct in the nominal case, at least for the given key size and message size. But it isn't enough to have a lot of confidence in your code. You should at least test some different key sizes and message sizes. Usually the only way to obtain sufficient test data is by running one or more known-good implementation.



              As an added difficulty, some algorithms are randomized, for example RSA-PSS signature and any form of encryption. To use test vectors, you need to be able to configure your implementation to use a “fake” random stream that is identical to the random stream used to generate the test vectors. To compare with another implementation, the two implementations need to use the same random stream. This isn't always possible. If you can't do that, you can make interoperability tests. For example, encrypt with one implementation and decrypt with another implementation.



              OpenSSL is a popular cryptography library, but it isn't always easy to use. Cryptodome is a Python library that I find convenient to generate test vectors.






              share|improve this answer























                up vote
                0
                down vote










                up vote
                0
                down vote









                The most common way to generate test data for a cryptography algorithm is to use another implementation of this algorithm that you trust. This lets you generate as much test data as you like, with whatever key size, message size, etc. that you desire.



                This is the way cryptography implementations are functionally validated in the real world. Sometimes it's done by using a known-good implementation, generating test data, and checking that the new implementation generates the same results. Sometimes it's done by running two or more implementations in parallel on the same inputs and checking that they generate the same results.



                How, you may ask, was the very first implementation validated? It depends. Usually the very first implementation is written in the most straightforward manner possible. No optimizations, no side channel resistance and other complications. Then people carefully review it against the English or mathematical description of the algorithm. Then someone else independently writes their own implementation and compares the results with the first.



                Most specifications of cryptographic algorithms contain a few sample inputs and outputs. In cryptography, these are called “test vectors”. NIST CAVP has longer lists of test vectors for algorithms that NIST approves of. Given the nature of cryptographic calculations, just getting one test vector right is usually enough to show that your implementation is basically correct in the nominal case, at least for the given key size and message size. But it isn't enough to have a lot of confidence in your code. You should at least test some different key sizes and message sizes. Usually the only way to obtain sufficient test data is by running one or more known-good implementation.



                As an added difficulty, some algorithms are randomized, for example RSA-PSS signature and any form of encryption. To use test vectors, you need to be able to configure your implementation to use a “fake” random stream that is identical to the random stream used to generate the test vectors. To compare with another implementation, the two implementations need to use the same random stream. This isn't always possible. If you can't do that, you can make interoperability tests. For example, encrypt with one implementation and decrypt with another implementation.



                OpenSSL is a popular cryptography library, but it isn't always easy to use. Cryptodome is a Python library that I find convenient to generate test vectors.






                share|improve this answer












                The most common way to generate test data for a cryptography algorithm is to use another implementation of this algorithm that you trust. This lets you generate as much test data as you like, with whatever key size, message size, etc. that you desire.



                This is the way cryptography implementations are functionally validated in the real world. Sometimes it's done by using a known-good implementation, generating test data, and checking that the new implementation generates the same results. Sometimes it's done by running two or more implementations in parallel on the same inputs and checking that they generate the same results.



                How, you may ask, was the very first implementation validated? It depends. Usually the very first implementation is written in the most straightforward manner possible. No optimizations, no side channel resistance and other complications. Then people carefully review it against the English or mathematical description of the algorithm. Then someone else independently writes their own implementation and compares the results with the first.



                Most specifications of cryptographic algorithms contain a few sample inputs and outputs. In cryptography, these are called “test vectors”. NIST CAVP has longer lists of test vectors for algorithms that NIST approves of. Given the nature of cryptographic calculations, just getting one test vector right is usually enough to show that your implementation is basically correct in the nominal case, at least for the given key size and message size. But it isn't enough to have a lot of confidence in your code. You should at least test some different key sizes and message sizes. Usually the only way to obtain sufficient test data is by running one or more known-good implementation.



                As an added difficulty, some algorithms are randomized, for example RSA-PSS signature and any form of encryption. To use test vectors, you need to be able to configure your implementation to use a “fake” random stream that is identical to the random stream used to generate the test vectors. To compare with another implementation, the two implementations need to use the same random stream. This isn't always possible. If you can't do that, you can make interoperability tests. For example, encrypt with one implementation and decrypt with another implementation.



                OpenSSL is a popular cryptography library, but it isn't always easy to use. Cryptodome is a Python library that I find convenient to generate test vectors.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 12 at 22:22









                Gilles

                7,43732552




                7,43732552






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Cryptography 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.


                    Use MathJax to format equations. MathJax reference.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • 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%2fcrypto.stackexchange.com%2fquestions%2f63874%2fneed-a-test-suite-for-my-rsa-implementation%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

                    Bressuire

                    Vorschmack

                    Quarantine