Re: encrypting long strings
On 19-07-2010 14:32, Jeffrey Walton wrote: On Wed, Jul 14, 2010 at 6:42 AM, Jakob Bohm wrote: On 14-07-2010 07:52, Jeffrey Walton wrote: On Tue, Jul 13, 2010 at 3:04 PM, Jakob Bohmwrote: [SNIP] proponents of the RSA and DH algorithms said that the number was wildly exaggerated and proposed some much smaller values. I'm not willing to go out on a limb a recommend a smaller moduli (what is RSA recommending, BTW?). I look at it this way: When DSS was proposed, RSA Data Securities lobbied hard to get an RSA Signature included. They can't win them all Yes, that mostly dead company lost the political lobbying battle against Certicom, but I was asking about science, not politics. http://scholar.google.com/scholar?hl=en&q=integer+factorization+estimate&as_sdt=2000&as_ylo=2008&as_vis=0 After looking at some of the rather mixed bag of documents from that search, I was able to spot only the following factoid, which I post here for the benefit of the rest of the list (and I hope this one is right). The needed size of RSA moduli increases approximately with the cube of the equivalent symmetric key size, thus if 128 bit AES corresponds to L bit RSA, 256 bit AES should correspond to 8L bit RSA. I did not spot an article that seemed to give estimates for the actual RSA key lengths corresponding to modern symmetric key lengths. Make sure to have a look a Lenstra, et. al. "On the Security of 1024-bit RSA and 160-bit Elliptic Curve Cryptography". Not quite what you were asking for but a very thorough analysis. Ah, nice article which did not turn up in the initial search you suggested. From this article and the other information I believe that the public key lengths needed to achieve N bits of security is: RSA/DH (N/7.5)**3 ECC N*2 Thus (with some rounding): 128 bits: 5120 bit RSA/DH or 256 bit ECC 192 bits: 16384 bit RSA/DH or 384 bit ECC 256 bits: 40960 bit RSA/DH or 512 bit ECC which is not that far off from some other recommendations. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
On Wed, Jul 14, 2010 at 6:42 AM, Jakob Bohm wrote: > On 14-07-2010 07:52, Jeffrey Walton wrote: >> >> On Tue, Jul 13, 2010 at 3:04 PM, Jakob Bohm wrote: >>> >>> [SNIP] >> > proponents of the RSA and DH algorithms said that the > number was wildly exaggerated and proposed some much > smaller values. I'm not willing to go out on a limb a recommend a smaller moduli (what is RSA recommending, BTW?). I look at it this way: When DSS was proposed, RSA Data Securities lobbied hard to get an RSA Signature included. They can't win them all >>> >>> Yes, that mostly dead company lost the political lobbying battle against >>> Certicom, but I was asking about science, not politics. >> >> http://scholar.google.com/scholar?hl=en&q=integer+factorization+estimate&as_sdt=2000&as_ylo=2008&as_vis=0 >> > After looking at some of the rather mixed bag of documents from that > search, I was able to spot only the following factoid, which I post here > for the benefit of the rest of the list (and I hope this one is right). > > The needed size of RSA moduli increases approximately with the cube > of the equivalent symmetric key size, thus if 128 bit AES corresponds > to L bit RSA, 256 bit AES should correspond to 8L bit RSA. > > I did not spot an article that seemed to give estimates for the > actual RSA key lengths corresponding to modern symmetric key lengths. Make sure to have a look a Lenstra, et. al. "On the Security of 1024-bit RSA and 160-bit Elliptic Curve Cryptography". Not quite what you were asking for but a very thorough analysis. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
On 14-07-2010 07:52, Jeffrey Walton wrote: On Tue, Jul 13, 2010 at 3:04 PM, Jakob Bohm wrote: On 13-07-2010 15:00, Jeffrey Walton wrote: [SNIP] proponents of the RSA and DH algorithms said that the number was wildly exaggerated and proposed some much smaller values. I'm not willing to go out on a limb a recommend a smaller moduli (what is RSA recommending, BTW?). I look at it this way: When DSS was proposed, RSA Data Securities lobbied hard to get an RSA Signature included. They can't win them all Yes, that mostly dead company lost the political lobbying battle against Certicom, but I was asking about science, not politics. http://scholar.google.com/scholar?hl=en&q=integer+factorization+estimate&as_sdt=2000&as_ylo=2008&as_vis=0 After looking at some of the rather mixed bag of documents from that search, I was able to spot only the following factoid, which I post here for the benefit of the rest of the list (and I hope this one is right). The needed size of RSA moduli increases approximately with the cube of the equivalent symmetric key size, thus if 128 bit AES corresponds to L bit RSA, 256 bit AES should correspond to 8L bit RSA. I did not spot an article that seemed to give estimates for the actual RSA key lengths corresponding to modern symmetric key lengths. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
On Tue, Jul 13, 2010 at 3:04 PM, Jakob Bohm wrote: > On 13-07-2010 15:00, Jeffrey Walton wrote: > [SNIP] >>> proponents of the RSA and DH algorithms said that the >>> number was wildly exaggerated and proposed some much >>> smaller values. >> >> I'm not willing to go out on a limb a recommend a smaller moduli (what >> is RSA recommending, BTW?). I look at it this way: When DSS was >> proposed, RSA Data Securities lobbied hard to get an RSA Signature >> included. They can't win them all >> > > Yes, that mostly dead company lost the political lobbying battle against > Certicom, but I was asking about science, not politics. http://scholar.google.com/scholar?hl=en&q=integer+factorization+estimate&as_sdt=2000&as_ylo=2008&as_vis=0 > [SNIP] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
On 13-07-2010 15:00, Jeffrey Walton wrote: Hi Jakob, Are you sure about those numbers? Yes. See SP800-57 [1]. I know SP800-57 says it, see below. I know that proponents of ECC cryptography have been roundly criticized for putting forward those specific numbers and for talking NIST into repeating them in their official publications. Many of the folks I work with want the FIPs conformance - especially for the sales literature. There's no way I can side step it, regardless of how RSA Data Security feels about it For FIPS compliance there is no way around a lot of dubious rules, such as not using algorithms not yet approved by NIST, not using assembler optimizations (for the higher FIPS 140-2 levels) etc. proponents of the RSA and DH algorithms said that the number was wildly exaggerated and proposed some much smaller values. I'm not willing to go out on a limb a recommend a smaller moduli (what is RSA recommending, BTW?). I look at it this way: When DSS was proposed, RSA Data Securities lobbied hard to get an RSA Signature included. They can't win them all Yes, that mostly dead company lost the political lobbying battle against Certicom, but I was asking about science, not politics. On Mon, Jul 12, 2010 at 10:16 AM, Jakob Bohm wrote: On 10-07-2010 20:13, Jeffrey Walton wrote: The general approach is to encrypt data using a symmetric cipher (e.g., AES-256) with a randomly-generated key, and then encrypt that symmetric key with the RSA (public) key. AES-256 requires a RSA modulus with an equivalent strength, which is a 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by orders of magnitude. Are you sure about those numbers? I know that proponents of ECC cryptography have been roundly criticized for putting forward those specific numbers and for talking NIST into repeating them in their official publications. When the 15360 bit number was put forward as the RSA and DH key length needed to match the strength of 256 bit ECC keys, proponents of the RSA and DH algorithms said that the number was wildly exaggerated and proposed some much smaller values. I don't know if the general crypto research community has since formed a consensus on what the real numbers are. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
Hi Jakob, > Are you sure about those numbers? Yes. See SP800-57 [1]. > I know that proponents of ECC cryptography have been roundly > criticized for putting forward those specific numbers and for > talking NIST into repeating them in their official publications. Many of the folks I work with want the FIPs conformance - especially for the sales literature. There's no way I can side step it, regardless of how RSA Data Security feels about it > proponents of the RSA and DH algorithms said that the > number was wildly exaggerated and proposed some much > smaller values. I'm not willing to go out on a limb a recommend a smaller moduli (what is RSA recommending, BTW?). I look at it this way: When DSS was proposed, RSA Data Securities lobbied hard to get an RSA Signature included. They can't win them all Jeff [1] SP800-57, p63 (http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf) On Mon, Jul 12, 2010 at 10:16 AM, Jakob Bohm wrote: > On 10-07-2010 20:13, Jeffrey Walton wrote: >>> >>> The general approach is to encrypt data using a symmetric cipher (e.g., >>> AES-256) with a randomly-generated key, and then encrypt that symmetric >>> key >>> with the RSA (public) key. >> >> AES-256 requires a RSA modulus with an equivalent strength, which is a >> 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by >> orders of magnitude. >> > > Are you sure about those numbers? I know that proponents of ECC > cryptography have been roundly criticized for putting forward those > specific numbers and for talking NIST into repeating them in their > official publications. > > When the 15360 bit number was put forward as the RSA and DH key length > needed to match the strength of 256 bit ECC keys, proponents of the RSA > and DH algorithms said that the number was wildly exaggerated and > proposed some much smaller values. I don't know if the general crypto > research community has since formed a consensus on what the real > numbers are. > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
On 12-07-2010 16:54, Victor Duchovni wrote: On Mon, Jul 12, 2010 at 04:16:13PM +0200, Jakob Bohm wrote: On 10-07-2010 20:13, Jeffrey Walton wrote: The general approach is to encrypt data using a symmetric cipher (e.g., AES-256) with a randomly-generated key, and then encrypt that symmetric key with the RSA (public) key. AES-256 requires a RSA modulus with an equivalent strength, which is a 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by orders of magnitude. Are you sure about those numbers? I know that proponents of ECC cryptography have been roundly criticized for putting forward those specific numbers and for talking NIST into repeating them in their official publications. AES 256 does not "require" an RSA key that has an equal cost to brute-force. However, the numbers are based on estimates from best known attack algorithms, and these estimate 2n-bit ECC at n-bit symmetric, while for RSA the bit length is non-linear in the "equivalent" symmetric key size, and matching 256-bit AES is unrealistic. That was not my question. My question was about the actual numeric values in that non-linear mapping from symmetric key sizes to RSA modulus sizes. A few years ago there was public controversy about what RSA key lengths correspond to 256 bit symmetric keys length. Some said 15360 bits, some said less. NIST republished 15360 in some of their documents without giving a reason. Not too many advocate AES 256 + ~512 bit ECC either. Instead, NSA Suite-B for example, one sees "balanced" combinations like AES-128 + ECC-256 or AES-192 + ECC-384. The absence of NIST's ECC-512 curve from the Suite B lists is mysterious at best. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
On Mon, Jul 12, 2010 at 04:16:13PM +0200, Jakob Bohm wrote: > On 10-07-2010 20:13, Jeffrey Walton wrote: >>> The general approach is to encrypt data using a symmetric cipher (e.g., >>> AES-256) with a randomly-generated key, and then encrypt that symmetric >>> key >>> with the RSA (public) key. >> AES-256 requires a RSA modulus with an equivalent strength, which is a >> 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by >> orders of magnitude. >> > > Are you sure about those numbers? I know that proponents of ECC > cryptography have been roundly criticized for putting forward those > specific numbers and for talking NIST into repeating them in their > official publications. AES 256 does not "require" an RSA key that has an equal cost to brute-force. However, the numbers are based on estimates from best known attack algorithms, and these estimate 2n-bit ECC at n-bit symmetric, while for RSA the bit length is non-linear in the "equivalent" symmetric key size, and matching 256-bit AES is unrealistic. Not too many advocate AES 256 + ~512 bit ECC either. Instead, NSA Suite-B for example, one sees "balanced" combinations like AES-128 + ECC-256 or AES-192 + ECC-384. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
On 10-07-2010 20:13, Jeffrey Walton wrote: The general approach is to encrypt data using a symmetric cipher (e.g., AES-256) with a randomly-generated key, and then encrypt that symmetric key with the RSA (public) key. AES-256 requires a RSA modulus with an equivalent strength, which is a 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by orders of magnitude. Are you sure about those numbers? I know that proponents of ECC cryptography have been roundly criticized for putting forward those specific numbers and for talking NIST into repeating them in their official publications. When the 15360 bit number was put forward as the RSA and DH key length needed to match the strength of 256 bit ECC keys, proponents of the RSA and DH algorithms said that the number was wildly exaggerated and proposed some much smaller values. I don't know if the general crypto research community has since formed a consensus on what the real numbers are. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
Hi Phillip, > You make it sound like the AES algorithm itself somehow imposes requirements > on how its key can be protected. The best I can tell, we said the same thing. The security levels among AES and RSA are equivalent. Jeff On Sun, Jul 11, 2010 at 12:29 AM, Phillip Hellewell wrote: > On Sat, Jul 10, 2010 at 12:13 PM, Jeffrey Walton wrote: >> >> > The general approach is to encrypt data using a symmetric cipher (e.g., >> > AES-256) with a randomly-generated key, and then encrypt that symmetric >> > key >> > with the RSA (public) key. >> AES-256 requires a RSA modulus with an equivalent strength, which is a >> 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by >> orders of magnitude. > > You make it sound like the AES algorithm itself somehow imposes requirements > on how its key can be protected. > > I would say it more like this: "A 256-bit AES key ought to be encrypted with > an equivalent strength RSA key, 15360-bit, otherwise its resistance to > attack is reduced to the strength of the RSA key." > > Or maybe like this: "If you choose a 2048-bit RSA key to protect the AES > key, you might as well use AES-128, since AES-256 won't buy you any > additional strength." > > Phillip > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
Despite what others have said, RSA is perfectly reasonable (if slow) to use for encryption. If you do, you should use OAEP/OAEP+ rather than the common/naive method of padding. http://cseweb.ucsd.edu/~mihir/papers/oaep.html The Wikipedia article is a good starting place http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding and there's a brief article here http://www.rsa.com/rsalabs/node.asp?id=2346 more detail here ftp://ftp.rsasecurity.com/pub/rsalabs/rsa_algorithm/rsa-oaep_spec.pdf - M On Sat, Jul 10, 2010 at 11:13 AM, Jeffrey Walton wrote: > > The general approach is to encrypt data using a symmetric cipher (e.g., > > AES-256) with a randomly-generated key, and then encrypt that symmetric > key > > with the RSA (public) key. > AES-256 requires a RSA modulus with an equivalent strength, which is a > 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by > orders of magnitude. > > On Thu, Jul 8, 2010 at 11:43 PM, Phillip Hellewell > wrote: > > The general approach is to encrypt data using a symmetric cipher (e.g., > > AES-256) with a randomly-generated key, and then encrypt that symmetric > key > > with the RSA (public) key. > > > > And for the symmetric encryption you'll also have to make a decision > about > > what mode to use (ECB, CBC, CTR, etc). Whatever you do, don't use ECB :) > > > > Phillip > > > > On Thu, Jul 8, 2010 at 7:40 PM, Chuck Pareto > wrote: > >> > >> Is there an algorithm that I can use, similar to RSA with public/private > >> key, that will allow me to encrypt really long strings (like an > email/text > >> file)? Actually no limit on the size would be ideal. > > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: encrypting long strings
On Sat, Jul 10, 2010 at 12:13 PM, Jeffrey Walton wrote: > > The general approach is to encrypt data using a symmetric cipher (e.g., > > AES-256) with a randomly-generated key, and then encrypt that symmetric > key > > with the RSA (public) key. > AES-256 requires a RSA modulus with an equivalent strength, which is a > 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by > orders of magnitude. You make it sound like the AES algorithm itself somehow imposes requirements on how its key can be protected. I would say it more like this: "A 256-bit AES key ought to be encrypted with an equivalent strength RSA key, 15360-bit, otherwise its resistance to attack is reduced to the strength of the RSA key." Or maybe like this: "If you choose a 2048-bit RSA key to protect the AES key, you might as well use AES-128, since AES-256 won't buy you any additional strength." Phillip
Re: encrypting long strings
> The general approach is to encrypt data using a symmetric cipher (e.g., > AES-256) with a randomly-generated key, and then encrypt that symmetric key > with the RSA (public) key. AES-256 requires a RSA modulus with an equivalent strength, which is a 15360 (IIRC). If you choose RSA-1024 or RSA-2048, you are off by orders of magnitude. On Thu, Jul 8, 2010 at 11:43 PM, Phillip Hellewell wrote: > The general approach is to encrypt data using a symmetric cipher (e.g., > AES-256) with a randomly-generated key, and then encrypt that symmetric key > with the RSA (public) key. > > And for the symmetric encryption you'll also have to make a decision about > what mode to use (ECB, CBC, CTR, etc). Whatever you do, don't use ECB :) > > Phillip > > On Thu, Jul 8, 2010 at 7:40 PM, Chuck Pareto wrote: >> >> Is there an algorithm that I can use, similar to RSA with public/private >> key, that will allow me to encrypt really long strings (like an email/text >> file)? Actually no limit on the size would be ideal. > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
Hi, Of course the randomly-generated symmetric key is not public! Otherwise, everyone can decrypt your data. The only thing that is public is the RSA public key. For decryption, you only need the RSA private key. It will be used to decrypt the symmetric key and then with the later you will decrypt your string. I hope this clarifies things to you. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr > Hi, > Thanks for the reply Phillip. One quick question. Is the > randomly-generated > key PUBLIC? I know the public RSA key to encrypt the key is public, but is > the randomly-generated key PUBLIC? > Thanks. > > On Thu, Jul 8, 2010 at 8:43 PM, Phillip Hellewell > wrote: > >> The general approach is to encrypt data using a symmetric cipher (e.g., >> AES-256) with a randomly-generated key, and then encrypt that symmetric >> key >> with the RSA (public) key. >> >> And for the symmetric encryption you'll also have to make a decision >> about >> what mode to use (ECB, CBC, CTR, etc). Whatever you do, don't use ECB >> :) >> >> Phillip >> >> >> On Thu, Jul 8, 2010 at 7:40 PM, Chuck Pareto >> wrote: >> >>> Is there an algorithm that I can use, similar to RSA with >>> public/private >>> key, that will allow me to encrypt really long strings (like an >>> email/text >>> file)? Actually no limit on the size would be ideal. >>> >> >> > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: encrypting long strings
Hi, Thanks for the reply Phillip. One quick question. Is the randomly-generated key PUBLIC? I know the public RSA key to encrypt the key is public, but is the randomly-generated key PUBLIC? Thanks. On Thu, Jul 8, 2010 at 8:43 PM, Phillip Hellewell wrote: > The general approach is to encrypt data using a symmetric cipher (e.g., > AES-256) with a randomly-generated key, and then encrypt that symmetric key > with the RSA (public) key. > > And for the symmetric encryption you'll also have to make a decision about > what mode to use (ECB, CBC, CTR, etc). Whatever you do, don't use ECB :) > > Phillip > > > On Thu, Jul 8, 2010 at 7:40 PM, Chuck Pareto wrote: > >> Is there an algorithm that I can use, similar to RSA with public/private >> key, that will allow me to encrypt really long strings (like an email/text >> file)? Actually no limit on the size would be ideal. >> > >
Re: encrypting long strings
The general approach is to encrypt data using a symmetric cipher (e.g., AES-256) with a randomly-generated key, and then encrypt that symmetric key with the RSA (public) key. And for the symmetric encryption you'll also have to make a decision about what mode to use (ECB, CBC, CTR, etc). Whatever you do, don't use ECB :) Phillip On Thu, Jul 8, 2010 at 7:40 PM, Chuck Pareto wrote: > Is there an algorithm that I can use, similar to RSA with public/private > key, that will allow me to encrypt really long strings (like an email/text > file)? Actually no limit on the size would be ideal. >