Need a test suite for my RSA implementation
up vote
5
down vote
favorite
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
add a comment |
up vote
5
down vote
favorite
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
add a comment |
up vote
5
down vote
favorite
up vote
5
down vote
favorite
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
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
rsa test-vectors
edited Nov 12 at 1:58
kiwidrew
3739
3739
asked Nov 11 at 12:41
user63361
311
311
add a comment |
add a comment |
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.
Thank you so much :) That is all what I need
– user63361
Nov 11 at 14:01
add a comment |
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.
.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
add a comment |
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.
add a comment |
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.
Thank you so much :) That is all what I need
– user63361
Nov 11 at 14:01
add a comment |
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.
Thank you so much :) That is all what I need
– user63361
Nov 11 at 14:01
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
.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
add a comment |
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.
.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
add a comment |
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.
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.
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
add a comment |
.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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 12 at 22:22
Gilles
7,43732552
7,43732552
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown