Re: RSA key conversion
Hello, > Hi, I'm developing a client-server architecture to encrypt/decrypt > data which works like this: the client asks the server for the key > using a ssl connection, the server transmits the key to the client that > then encrypts/decrypts the data. > > I'd like to know if there is a way to convert a RSA* key object into a > string (and vice versa) to be transmitted over a ssl socket. > Is there a way to do this? Look at d2i_RSAPrivateKey()/i2d_RSAPrivateKey()/i2d_RSAPublicKey()/d2i_RSAPublicKey() functions. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key conversion
On 9/27/07, Marek Marcola <[EMAIL PROTECTED]> wrote: > Hello, > > Hi, I'm developing a client-server architecture to encrypt/decrypt > > data which works like this: the client asks the server for the key > > using a ssl connection, the server transmits the key to the client that > > then encrypts/decrypts the data. > > > > I'd like to know if there is a way to convert a RSA* key object into a > > string (and vice versa) to be transmitted over a ssl socket. > > Is there a way to do this? > Look at > d2i_RSAPrivateKey()/i2d_RSAPrivateKey()/i2d_RSAPublicKey()/d2i_RSAPublicKey() > functions. Ok, thank you. They seems exactly what I've been looking for. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA Key Block
Hello, > I have a general question about RSA Key Block. Maybe key_material is more precise. > The output of PRF with the master_secret to give us many keys. It > includes: client_write_MAC_secret, server_wriet_MAC_secret, > client_write_key, server_write_key, client_write_IV, server_write_IV. > Could you Please verify what I think about how four of these keys > being use correcly: > > 1) SSL record format: Length + Data + MAC ( in general) : client> > server > > client_write_MAC_secret is used to encrypted the MAC portion > message from client>server > client_write_key is used to encrypted the Data portion message > from client> server SSL data record is build from ssl_record_header, application_data and MAC where application_data and MAC is encrypted. When writing packet from client to server first thing is to calculate MAC data, but in TLS1 this is not simple SHA1() or MD5() but HMAC_SHA1() or HMAC_MD5(). This functions requires some key (client_write_MAC_secret in this case) and data to calculate MAC. In this case data is: data = write_seq_num + proto + version + application_data_len + application_data and than, MAC is calculated as (for SHA1): MAC = HMAC_SHA1(client_write_MAC_secret, data) This MAC is concatenated to application_data, some padding is added too and all this is encrypted using client_write_key (with IV for CBC). > 2) SSL record format: Length + Data + MAC ( in general) : server> > client > > servert_write_MAC_secret is used to encrypted the MAC portion > message from server> client > client_write_key is used to encrypted the Data portion message > from server> client Like above but with different keys. > 3) Data from Sever to Client is encrypted with different key from > Client to Server ???. Yes. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA Key Uniqueness
On Thursday 18 Mar 2004 16:14, Gerrit E.G. 'Insh_Allah' Hobbelt wrote: > Hi Andrew, > > > How unique is it? Is it statistically improbable that I could generate > > the same key twice? > > If you have properly seeded your random generator, generated (RSA) keys > should be quite unique. > Here is a simple description of WhiteWater which explains what I'm doing. You'll see why I asked the question, and it perhaps answers some of your counter-questions. Comments/criticism gratefully accepted... "Whitewater is a cross between bittorrent and an anonymous file server, and handles multiple files (like the whole package source tree in rubyx) Basically, there are two binaries, wws - White Water Server wwc - White Water Client wws is a daemon which provides the data store, and wwc is used to talk to a wws. First, understand asymetric cryptography. You generate a key-pair. The public key is used to encrypt (lock) data. It can only be decrypted (unlocked) with the private key. You can extract the public key from the private key when you need it, but obviously not the other way round. You can give out your public key to anyone who needs to send you encrypted data, but only you can decrypt it with the private key. To 'distribute' a file (make it available from a wws) you would do wwc --server ww.rubyx.org --distribute myfile > private-key wwc generates a new (unique) key-pair and encrypts the file using the public key. It then makes a connection to the wws running on ww.rubyx.org, and uploads the encrypted file to the wws server, along with the public key. The wws server splits the file into lots of small chunks (currently 50k each; testing will provide optimal size) and calculates an md5sum for each chunk. It then stores the chunks in it's data cache, accessible via their md5sums. It also stores the array of md5sums needed to recreate the entire encrypted file in a catalogue hash, referenced via it's public key. wws now stores the data, which it can reference with the public key, but it has no idea what the data is and has no means of decrypting it. It is a true anonymous fileserver; Fully obfuscated and with plausible deniability :) wwc then sends the private key to stdout. In the example above, the private key is stored in the file private-key. At no time did the private key leave wwc running on the local machine. To access a file, you supply the private key to wwc. wwc --server ww.rubyx.org --get private-key > myfile wwc extracts the public key from the private key, connects to the wws on ww.rubyx.org and sends it the public key. wws looks up the public key in the catalogue hash and returns the array of md5sums of the chunks required to reconstitute the file. wwc, for each chunk/md5sum then requests the ip of a cooperating server which has that chunk from the wws on ww.rubyx.org. It contacts each of these other wws servers and requests the relevant chunk (by specifying the md5sum). Note these downloads are done in parallel so you should always achieve near the maximum download speed according to your available bandwidth. (As with bittorrent, the more downloads, the faster it gets) All recieved chunks are checked against their own md5sum, and bad or non responsive servers are reported to the wws on ww.rubyx.org and an alternative wws ip requested. Once wwc has all the required chunks and has reconstituted the file, it is decrypted using the private key and sent to stdout. In the example above, the data is sent to myfile Users wanting to lend (a small amount of) upstream bandwidth to the cause will run their own wws like this wws --parent ww.rubyx.org and use wwc --server localhost in the above examples. The local wws informs the parent of it presence and the md5sums of the chunks it has in its data cache. This is better than bittorrent (as I understand it) because it can share other data than just that which it is currently downloading. Thats roughly what happens. Pretty simple I think you'll agree, but Whitewater combines the benefits of bittorrent with those of an anonymous file server." __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Key Uniqueness
I don't see that you should be using public key encryption here. Why don't you just make a secret key, encrypt your data, send the data and a reference along with it, and output the secret key and the reference? Public key operations are slow. If you intend to encrypt an entire file with the public key alg (as opposed to encrypting just a secret key that's then used to encrypt the data) you can expect a lot of time spent on compression and decompression. One RSA implementation I've used does about 30,000 bytes/sec with a 1024 bit key on a p3 1.2 ghz. You'll also need to pad any data - which is 2:1 padding to data (varies by padding method I think?), so you end up with ~3x the original size. The usual operation is to use a shared secret key to encrypt the actual bulk of the data you want to transfer. The public key is used to encrypt the shared secret key, since you need a way to transfer that key from location A - > location B through "hostile territory". In your situation the secret key stays in a single location, so there's no need to provide security to transport it anywhere. Additionally you might consider ways to hide the size and source of data. Also, by linking the public key with the file you give the person running the server the ability to replace your data. They take a replacement file, encrypt it with the public key you gave them for reference, and now you get back whatever they encrypted. If you use a block encryption method they can replace individual blocks. If someone knows a bit about you they can probably use your habits, the current situation, and the size of the file to make a pretty good guess as to what's inside - which can give them a good idea what they could replace it with that might cause the most problems for you. Andrew Mann Andrew Walrond wrote: On Thursday 18 Mar 2004 16:14, Gerrit E.G. 'Insh_Allah' Hobbelt wrote: Hi Andrew, How unique is it? Is it statistically improbable that I could generate the same key twice? If you have properly seeded your random generator, generated (RSA) keys should be quite unique. Here is a simple description of WhiteWater which explains what I'm doing. You'll see why I asked the question, and it perhaps answers some of your counter-questions. Comments/criticism gratefully accepted... "Whitewater is a cross between bittorrent and an anonymous file server, and handles multiple files (like the whole package source tree in rubyx) Basically, there are two binaries, wws - White Water Server wwc - White Water Client wws is a daemon which provides the data store, and wwc is used to talk to a wws. First, understand asymetric cryptography. You generate a key-pair. The public key is used to encrypt (lock) data. It can only be decrypted (unlocked) with the private key. You can extract the public key from the private key when you need it, but obviously not the other way round. You can give out your public key to anyone who needs to send you encrypted data, but only you can decrypt it with the private key. To 'distribute' a file (make it available from a wws) you would do wwc --server ww.rubyx.org --distribute myfile > private-key wwc generates a new (unique) key-pair and encrypts the file using the public key. It then makes a connection to the wws running on ww.rubyx.org, and uploads the encrypted file to the wws server, along with the public key. The wws server splits the file into lots of small chunks (currently 50k each; testing will provide optimal size) and calculates an md5sum for each chunk. It then stores the chunks in it's data cache, accessible via their md5sums. It also stores the array of md5sums needed to recreate the entire encrypted file in a catalogue hash, referenced via it's public key. wws now stores the data, which it can reference with the public key, but it has no idea what the data is and has no means of decrypting it. It is a true anonymous fileserver; Fully obfuscated and with plausible deniability :) wwc then sends the private key to stdout. In the example above, the private key is stored in the file private-key. At no time did the private key leave wwc running on the local machine. To access a file, you supply the private key to wwc. wwc --server ww.rubyx.org --get private-key > myfile wwc extracts the public key from the private key, connects to the wws on ww.rubyx.org and sends it the public key. wws looks up the public key in the catalogue hash and returns the array of md5sums of the chunks required to reconstitute the file. wwc, for each chunk/md5sum then requests the ip of a cooperating server which has that chunk from the wws on ww.rubyx.org. It contacts each of these other wws servers and requests the relevant chunk (by specifying the md5sum). Note these downloads are done in parallel so you should always achieve near the maximum download speed according to your available bandwidth. (As with bittorrent, the mor
Re: RSA Key Uniqueness
Hi Andrew It was a good job I asked the question I think. Gerrit and yourself have caused me to sit down and learn a lot more about cryptography than I had intended, but it has been very useful. On Friday 19 Mar 2004 01:01, Andrew Mann wrote: > I don't see that you should be using public key encryption here. Why > don't you just make a secret key, encrypt your data, send the data and a > reference along with it, and output the secret key and the reference? I now intend to use symmetric encryption (probably blowfish) with an SHA hash as the reference (Which I now understand to be considered more collision resistant than MD5) > > Public key operations are slow. If you intend to encrypt an entire > file with the public key alg (as opposed to encrypting just a secret key > that's then used to encrypt the data) you can expect a lot of time spent > on compression and decompression. One RSA implementation I've used does > about 30,000 bytes/sec with a 1024 bit key on a p3 1.2 ghz. You'll also > need to pad any data - which is 2:1 padding to data (varies by padding > method I think?), so you end up with ~3x the original size. This alone makes my original implementtion untenable. Bandwidth is obviously a major concern for a file sharing application. > The usual operation is to use a shared secret key to encrypt the actual > bulk of the data you want to transfer. The public key is used to > encrypt the shared secret key, since you need a way to transfer that key > from location A - > location B through "hostile territory". In your > situation the secret key stays in a single location, so there's no need > to provide security to transport it anywhere. Now fully apprieciated :) > Additionally you might consider ways to hide the size and source of data. I understand size, but by source you mean who/where the data came from to protect against 'habit' attacks? > Also, by linking the public key with the file you give the person > running the server the ability to replace your data. They take a > replacement file, encrypt it with the public key you gave them for > reference, and now you get back whatever they encrypted. If you use a > block encryption method they can replace individual blocks. If someone > knows a bit about you they can probably use your habits, the current > situation, and the size of the file to make a pretty good guess as to > what's inside - which can give them a good idea what they could replace > it with that might cause the most problems for you. Understood. Your comments have been very useful. Thanks! Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: RSA Key Uniqueness
> Hi Andrew, > > How unique is it? Is it statistically improbable that I could > > generate the > > same key twice? > If you have properly seeded your random generator, generated > (RSA) keys should > be quite unique. It doesn't matter. Breaking an RSA key basically involves factoring a large near prime. A person could always factor a large near prime in very little time by just happening to guess one of its factors quite quickly. So no matter what you already have the risk that someone will happen to get lucky and break your key. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA key size.
Pawel Jakub Dawidek wrote: Hello. We're trying to get as small RSA private key as possible, because we are short in space (we want to store it on a smart card, so every byte is important). We found a way to cut it a bit by NULLing some pointers inside RSA structure: RSA *key; key->p = NULL; key->q = NULL; key->dmp1 = NULL; key->dmq1 = NULL; key->iqmp = NULL; and store it in DER format: i2d_RSAPrivateKey(key, &bufp); But, as you can see, it is a very hackish solution and we wonder if there is no more standard and clean way to implement this. How to store a rsa private key on a smartcard depends on what you want to do with the private key on the card. In case want to use a crypto card for, for example, signature generation the format of the private key is os specific. If you want to use the smartcard as a memory stick the format doesn't really matter. If you need a standard try pkcs#15, but pkcs#15 is not so easy to implement (and it creates a lot of overhead in this case). Nils __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA key sizes
On Wed, Aug 17, 2005 at 02:21:30PM +0800, Tan Eng Ten wrote: > This is a general crypto question and I hope someone could help me > out. > > Often we use RSA of 512, 1024, 2048, 4096, etc. bit lengths. Are > other sizes such as 520/1045 bit "valid"? Mathematically, it should > work, > but are there reasons why odd sizes are not to be used? Well RSA 512 is not (or should not be) used. As for the others, 768 is in fact used, then 1024 and 2048, I've not seen 4096 in real applications, one is likely better off with a different algorithm at that point. Non-standard sizes add no value, each incremental "standard" key size supports a particular expected security range. Stick to the standard sizes. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: RSA key sizes
I believe it's a matter of efficiency. There are optimisations that can be performed on the math of integers of length power-of-2. It's possible that there are implementations out there that won't work with non-standard sizes. I have seen 4096 bit keys in the wild. In fact, the Microsoft Root Certificate Authority key in the Microsoft Certificate Store is 4096 bits in length. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni Sent: Wednesday, 17 August 2005 4:45 PM To: openssl-users@openssl.org Subject: Re: RSA key sizes On Wed, Aug 17, 2005 at 02:21:30PM +0800, Tan Eng Ten wrote: > This is a general crypto question and I hope someone could help me > out. > > Often we use RSA of 512, 1024, 2048, 4096, etc. bit lengths. Are > other sizes such as 520/1045 bit "valid"? Mathematically, it should > work, but are there reasons why odd sizes are not to be used? Well RSA 512 is not (or should not be) used. As for the others, 768 is in fact used, then 1024 and 2048, I've not seen 4096 in real applications, one is likely better off with a different algorithm at that point. Non-standard sizes add no value, each incremental "standard" key size supports a particular expected security range. Stick to the standard sizes. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key sizes
On Wed, Aug 17, 2005, Tan Eng Ten wrote: > Hi all, > > This is a general crypto question and I hope someone could help me > out. > > Often we use RSA of 512, 1024, 2048, 4096, etc. bit lengths. Are > other sizes such as 520/1045 bit "valid"? Mathematically, it should > work, > but are there reasons why odd sizes are not to be used? One reason is interoperability. Some software (notably MS stuff based on CryptoAPI including MSIE) places restrictions on the key sizes and parameters. For public keys the only restriction is that the public exponent (e) can't exceeed 32 bits. For private keys the key size must be also be a multiple of 64 bits and every CRT parmeter must be either the key size of half the key size, this means that the two primes p and q must have the ame size for example. The main reason for this is that the internal format (PRIVATEKEYBLOB) has problems representing parameters which don't fit these criteria. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key sizes
Please note that the importance of RSA is going to decline in favor of Elliptic Curve Crypto over GF(p). In particular, by 2010 ECC will be mandated. I suspect there are cryptographic reasons for it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key structure
Pinca George wrote: > > Hello World , > > I saved a RSA key in DER format , whan I parse it I get something like this > : [stuff deleted] > > So the first integer After 0 is the modulus, then is the public exponent, > and then ? > Which is the private exponent I'll use for decrypting ? > The private exponent is the one after that. Its PKCS#1 format (see the PKCS standards on www.rsa.com) which you can use OpenSSL to print out with: openssl rsa -inform DER -noout -text Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA key generation error
Sorry for the stupid question, I have figured it out.
Thanks
JoeJoe smith <[EMAIL PROTECTED]> wrote:
Hi,
I have the following code
#include
#include
int main()
{
OpenSSL_add_all_algorithms();
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
RSA *rsa;
BIO *publickey;
ERR_load_crypto_strings();
rsa = RSA_generate_key(1024, 65537, NULL, NULL);
char *passwd = "123456";
FILE *F1 = fopen("key.pem", "wb");
PEM_write_RSAPrivateKey(F1, rsa, EVP_des_cbc(), NULL, 0, NULL, passwd);
// PEM_write_bio_RSAPublicKey(publickey,rsa);
fclose(F1);
FILE *F2 = fopen("key.pem", "rb");
RSA *rsa_2;
rsa_2 = PEM_read_RSAPrivateKey(F2, NULL, NULL, passwd);
char str[256];
ERR_error_string(ERR_get_error(), str);
printf(str);
}
but i am getting the following error
error::lib(0):func(0):reason(0)
Any suggestions,
Thanks
Joe
__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
Re: rsa key generation issue/question
Patrick Parsons wrote: > Hello, > I have noticed when generating rsa keys that the first 10 digits or so are > identical or nearly identical. Is this normal or is something wrong? Does > this issue occur for anyone else? could you post the bytes that you're referring to. (my guess is that it's the ASN.1 stuff again) -jb -- Tact is the art of making a point without making an enemy. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsa key generation issue/question
Hello, > I have noticed when generating rsa keys that the first 10 digits or > so are identical or nearly identical. Is this normal or is something > wrong? Does this issue occur for anyone else? > The version of openssl I am using is openssl-0.9.8b-8.3.fc6 and I am > using -rand /dev/urandom to seed the random number generator. This is part of ASN.1 encoding (0x30...). Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsa key generation issue/question
These are the first few bytes of the key. Here they are from 10 keys generated with the command: openssl genrsa -rand /dev/urandom MIIBOwIBAAJ MIIBOgIBAAJ MIIBPAIBAAJ MIIBPQIBAAJ MIIBOgIBAAJ MIIBOgIBAAJ MIIBOQIBAAJ MIIBOwIBAAJ MIIBOwIBAAJ MIIBOwIBAAJ On 8/9/07, jimmy bahuleyan <[EMAIL PROTECTED]> wrote: > Patrick Parsons wrote: > > Hello, > > I have noticed when generating rsa keys that the first 10 digits or so > are > > identical or nearly identical. Is this normal or is something wrong? Does > > this issue occur for anyone else? > > could you post the bytes that you're referring to. (my guess is that > it's the ASN.1 stuff again) > > -jb > -- > Tact is the art of making a point without making an enemy. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsa key generation issue/question
Looks like this may be the issue, a flaw in the key generation algorithm. https://www.kb.cert.org/vuls/id/724968 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsa key generation issue/question
Hello, > Looks like this may be the issue, a flaw in the key generation algorithm. > https://www.kb.cert.org/vuls/id/724968 Probably not, this is flow in Montgomery multiplication which is used in modular exponentation. Of course modular exponentation is used in key generation process in p,q prime test (Miller-Rabin) but this simply looks like ASN.1 encoding: $ echo MIIBOQIB | openssl base64 -d | hexdump -C 30 82 01 39 02 01 |0..9..| 0006 or (with some dirty hack) we may try to decode this 6 bytes: $ echo MIIBOQIB | (openssl base64 -d; dd if=/dev/urandom bs=1 count=2000) | openssl asn1parse -inform der 2000+0 records in 2000+0 records out 0:d=0 hl=4 l= 313 cons: SEQUENCE 4:d=1 hl=2 l= 1 prim: INTEGER :2C Error in encoding 18407:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:140: Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsa key generation issue/question
I am not familar with ASN.1, or any of the specifice of which the rsa key is generated. It just seemed as it should not be so. What is the ASN.1 encoding, and how is it used? On 8/9/07, Marek Marcola <[EMAIL PROTECTED]> wrote: > Hello, > > Looks like this may be the issue, a flaw in the key generation algorithm. > > https://www.kb.cert.org/vuls/id/724968 > Probably not, this is flow in Montgomery multiplication which is used > in modular exponentation. Of course modular exponentation is used > in key generation process in p,q prime test (Miller-Rabin) > but this simply looks like ASN.1 encoding: > > $ echo MIIBOQIB | openssl base64 -d | hexdump -C > 30 82 01 39 02 01 |0..9..| > 0006 > > or (with some dirty hack) we may try to decode this 6 bytes: > > $ echo MIIBOQIB | (openssl base64 -d; dd if=/dev/urandom bs=1 > count=2000) | openssl asn1parse -inform der > 2000+0 records in > 2000+0 records out > 0:d=0 hl=4 l= 313 cons: SEQUENCE > 4:d=1 hl=2 l= 1 prim: INTEGER :2C > Error in encoding > 18407:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too > long:asn1_lib.c:140: > > > > Best regards, > -- > Marek Marcola <[EMAIL PROTECTED]> > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsa key generation issue/question
Hello, > I am not familar with ASN.1, or any of the specifice of which the rsa > key is generated. It just seemed as it should not be so. > What is the ASN.1 encoding, and how is it used? RSA private key is a set of big numbers: n,d,e,p,q,dmp1,dmq1,iqmp. (this is not one number). When this numbers are saved to file there must be some method to distinguish this numbers. For RSA keys ASN.1 coding is used. For more information you may read PKCS#1 standard, in appendix A you will find ASN.1 structure of private key. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: rsa key generation issue/question
> I am not familar with ASN.1, or any of the specifice of which the rsa > key is generated. It just seemed as it should not be so. > What is the ASN.1 encoding, and how is it used? The vast majority of file formats begin with a header that is similar or identical for files that contain different data of the same type. The same is true for most human documents. If you had thirteen parking violations issued by the same officer, their first several words likely would be identical. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsa key generating with passphrase
On Sun, Feb 29, 2004, Claus Nagel wrote: > hello, I hope someone can help me with the following problem: > I'm trying to generate a rsa key pair in perl using the Crypt::RSA module. > this works fine so far. I am converting the resulting private key into PEM > format and it is checked ok by 'openssl rsa -in private.pem -check'. > now i want this private key to be protected by a passphrase using for > example AES-128-CBC encrypting. but I am not sure, what exactly is done with the > passphrase. is it used to generate a 128 bit key for the Rijndael algorithm? if > so, how is the passphrase converted to that key? > It is used along with a random salt to derive the key and IV. The algorithm used is unchanged since the SSLeay days. Check out the pem and EVP_bytestokey() manual pages. Other formats such as PKCS#8 are more standard and more secure though. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA key length and size
You should factor in the RSA speedups in your space estimates. Typically a public exponent of 2^16+1 is used so you need not pass this separately for a public key. However, the speedup for the private key operation involves all those other fields in a private key, which expands the space requirements needed considerably. While it is possible to do the private key operation with nothing other than the modulus and private exponent you should try to estimate how long the processor on the Java card would take (years? days? hours?). My gut feeling is that you will not be able to get both a private key and the data to be encrypted into 245 bytes. Erik Norgaard wrote: Hi, Sorry, I haven't written to the list before, if you know of sources of information that will answer my question, please just give me a link. I am programming a JavaCard v2.1, to provide encryption and decryption using either stored private/public keys or keys passed to the input data buffer. The input data buffer is just 245 bytes, and I want to pass the key and the data to be de/encrypted in one go to avoid problems with transient objects and risk of leaving the card in an insecure state. So my question is, say I have an RSA 1024 bit key, how much space does it actually ocupy? AFAIK 128bytes+exponent which is? For signature I need to fit in 20 bytes for a SHA1 digest, leaving some 225bytes for the key - is that possible. For encryption I need to fit in x bytes for a symmetric key to be encrypted - how long a symmetric key should I use? which algorithm? I could use a 768 bit key if that would make things possible. Given a certificate, how do I extract the modulus and exponent? Sorry, I am getting lost in all the different formats and encodings. But so far I only see a blob of data. Is there a standard way of packing modulus and exponent efficiently into a single blob? Thanks a lot, Erik -- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..." Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key length and size
Here's a crazy idea: The computer talking to the Java card rolls a random session key. In the first operation transfer a private key into the device, encrypted by the session key. In the second operation transfer the data to be encrypted and the session key. The Java card can decrypt the private key and use it. Now, the "insecure state" that occurs between the first and second transfer operation is not a vulnerability, because the adversary would need to know the session key to get the card to actually do anything with the private key? Erik Norgaard wrote: Hi, Sorry, I haven't written to the list before, if you know of sources of information that will answer my question, please just give me a link. I am programming a JavaCard v2.1, to provide encryption and decryption using either stored private/public keys or keys passed to the input data buffer. The input data buffer is just 245 bytes, and I want to pass the key and the data to be de/encrypted in one go to avoid problems with transient objects and risk of leaving the card in an insecure state. So my question is, say I have an RSA 1024 bit key, how much space does it actually ocupy? AFAIK 128bytes+exponent which is? For signature I need to fit in 20 bytes for a SHA1 digest, leaving some 225bytes for the key - is that possible. For encryption I need to fit in x bytes for a symmetric key to be encrypted - how long a symmetric key should I use? which algorithm? I could use a 768 bit key if that would make things possible. Given a certificate, how do I extract the modulus and exponent? Sorry, I am getting lost in all the different formats and encodings. But so far I only see a blob of data. Is there a standard way of packing modulus and exponent efficiently into a single blob? Thanks a lot, Erik -- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..." Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key length and size
Charles B Cranston wrote: You should factor in the RSA speedups in your space estimates. Typically a public exponent of 2^16+1 is used so you need not pass this separately for a public key. However, the speedup for the private key operation involves all those other fields in a private key, which expands the space requirements needed considerably. While it is possible to do the private key operation with nothing other than the modulus and private exponent you should try to estimate how long the processor on the Java card would take (years? days? hours?). My gut feeling is that you will not be able to get both a private key and the data to be encrypted into 245 bytes. Thanks, well, for normal operations the private key to be applied would be stored on the card. But from my experience, I have learnt not to implement restrictions of valid choices unless there is a very good reason. Eliptic Curves may be supported in future cards and solve the space problem. The amount of data that should be de-/encrypted is limited, for example the a symmetric key that is used to encrypt the actual message, or a digest to create a signature. So, I guess this concludes that for the practical puposes, there is room enough :-) Do you know any performance difference for the private key encryption with all components vs. only modulus and exponent? Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key length and size
Doing it the hard way requires roughly 1.5 times key length number of modular multiplies (assuming about half the bits are ones and half zeroes) so if the shortcutted public key operation takes 17 units of time the non-shortcutted private key operation takes about 1500 (assuming a 1000 bit key). Each operation is a multiply followed by a reduction modulo the modulus, or roughly a division operation (followed by discard of the quotient and retention of the remainder). Since the data is as many bits as the modulus this usually requires a fairly sophisticated subroutine. The two schemes I've seen are to do it one bit at a time (which only requires one comparison to find out what to do) or the algorithm in the RSAREF package which extracts an entire word of the quotient at a time. Pretty neat. Also consider: what happens in the future when you want to move to a 2048 or 4096 bit key? Do you have to wait for a more capable Java card to be marketed? Watch out for elliptic curve because a "message" usually takes sending TWO group elements, instead of just one as for RSA. This makes the message length twice as long as you otherwise might imagine. If you're just coding a session key for the real data this increase is minimal, but for the kind of embedded computation you're thinking of this can be a real gotcha. Erik Norgaard wrote: Charles B Cranston wrote: You should factor in the RSA speedups in your space estimates. Typically a public exponent of 2^16+1 is used so you need not pass this separately for a public key. However, the speedup for the private key operation involves all those other fields in a private key, which expands the space requirements needed considerably. While it is possible to do the private key operation with nothing other than the modulus and private exponent you should try to estimate how long the processor on the Java card would take (years? days? hours?). My gut feeling is that you will not be able to get both a private key and the data to be encrypted into 245 bytes. Thanks, well, for normal operations the private key to be applied would be stored on the card. But from my experience, I have learnt not to implement restrictions of valid choices unless there is a very good reason. Eliptic Curves may be supported in future cards and solve the space problem. The amount of data that should be de-/encrypted is limited, for example the a symmetric key that is used to encrypt the actual message, or a digest to create a signature. So, I guess this concludes that for the practical puposes, there is room enough :-) Do you know any performance difference for the private key encryption with all components vs. only modulus and exponent? Cheers, Erik -- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..." Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key length and size
Charles B Cranston wrote: Doing it the hard way requires roughly 1.5 times key length number of modular multiplies (assuming about half the bits are ones and half zeroes) so if the shortcutted public key operation takes 17 units of time the non-shortcutted private key operation takes about 1500 (assuming a 1000 bit key). Does this also apply to the old style keys or only in case of CRT type keys? Because, then, in any case I will have that problem when using the public key. Also consider: what happens in the future when you want to move to a 2048 or 4096 bit key? Do you have to wait for a more capable Java card to be marketed? The JavaCard supports RSA 2048 bits, and as of version 2.2 there is support of ECC up to 192 bits, but only for signature. I have a 2.1 card, but it is my intention not to predefine specific key types or lengths, these are chosen when the key is generated, such that newer card will support the new algorithms. The main problem as I see it is that for things to work, the input buffer must grow as longer keys are used or I must support sessions. Watch out for elliptic curve because a "message" usually takes sending TWO group elements, instead of just one as for RSA. This makes the message length twice as long as you otherwise might imagine. If you're just coding a session key for the real data this increase is minimal, but for the kind of embedded computation you're thinking of this can be a real gotcha. I have only been introduced to ECC, twice as long encrypted output is ok, the problem seems to be with decryption, then I might run out of space. Thanks for the info! Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key length and size
Erik Norgaard wrote: Charles B Cranston wrote: Doing it the hard way requires roughly 1.5 times key length number of modular multiplies (assuming about half the bits are ones and half zeroes) so if the shortcutted public key operation takes 17 units of time the non-shortcutted private key operation takes about 1500 (assuming a 1000 bit key). Does this also apply to the old style keys or only in case of CRT type keys? Because, then, in any case I will have that problem when using the public key. Not sure what you mean by old style and/or CRT type keys. If you have a public key with an exponent other than 65537 the public key operation may take longer, but I don't think that is within PKIX standards (other than 3 which does not take longer). Also consider: what happens in the future when you want to move to a 2048 or 4096 bit key? Do you have to wait for a more capable Java card to be marketed? The JavaCard supports RSA 2048 bits, and as of version 2.2 there is support of ECC up to 192 bits, but only for signature. Yes, but I was considering your original problem of getting both the key and the data to be encrypted into the 245 byte buffer. As the key gets longer this problem becomes more stringent. I have a 2.1 card, but it is my intention not to predefine specific key types or lengths, these are chosen when the key is generated, such that newer card will support the new algorithms. The main problem as I see it is that for things to work, the input buffer must grow as longer keys are used or I must support sessions. Watch out for elliptic curve because a "message" usually takes sending TWO group elements, instead of just one as for RSA. This makes the message length twice as long as you otherwise might imagine. If you're just coding a session key for the real data this increase is minimal, but for the kind of embedded computation you're thinking of this can be a real gotcha. I have only been introduced to ECC, twice as long encrypted output is ok, the problem seems to be with decryption, then I might run out of space. Thanks for the info! Actually this is more El Gamal vs RSA than the elliptic group vs the integer group, but it turns out that RSA on the elliptic group is not very much harder than on the integer group, so you DON'T get the same protection with a much shorter key. But if you use El Gamal you need to send two group elements, so the message size doubles compared to RSA in which only one group element needs to be sent. Hope all this helps! -- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..." Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key length and size
Charles B Cranston wrote: Doing it the hard way requires roughly 1.5 times key length number of modular multiplies (assuming about half the bits are ones and half zeroes) so if the shortcutted public key operation takes 17 units of time the non-shortcutted private key operation takes about 1500 (assuming a 1000 bit key). > Does this also apply to the old style keys or only in case of CRT type keys? Because, then, in any case I will have that problem when using the public key. Not sure what you mean by old style and/or CRT type keys. If you have a public key with an exponent other than 65537 the public key operation may take longer, but I don't think that is within PKIX standards (other than 3 which does not take longer). ok, maybe I misunderstood you. According to PKCS#1 the public key is a pair (n,e) and the private key can be respresented either as a pair (n,d) or in its Chinese Remainder Theorem form (CRT). The latter should be faster, but only applies for keys with more than two primefactors. Also consider: what happens in the future when you want to move to a 2048 or 4096 bit key? Do you have to wait for a more capable Java card to be marketed? Yes, but I was considering your original problem of getting both the key and the data to be encrypted into the 245 byte buffer. As the key gets longer this problem becomes more stringent. Well, a 2048 bit RSA key won't fit, so even now I hit the limit, but I read that 1024bit should be considerd safe till 2037 or something? so I decided to stick with 1024bit. The buffer size is defined in an ISO-standard, so changing this may not be so straight forward as launching a new card. However, the new version also supports Remote Method Invocation that is an abstraction layer, this may take care of all the transient data stuff :-) At this point I am developing a proof of concept, not even a prototype. So cutting some corners is ok if I have good reasons, I know where they are and what must be done to uncut them. I could have been straight naïve and simply assumed that the v2.1 was all I had to consider. Actually this is more El Gamal vs RSA than the elliptic group vs the integer group, but it turns out that RSA on the elliptic group is not very much harder than on the integer group, so you DON'T get the same protection with a much shorter key. But if you use El Gamal you need to send two group elements, so the message size doubles compared to RSA in which only one group element needs to be sent. > Hope all this helps! Absolutely, this is super! Thanks! Erik -- Ph: +34.666334818 web: http://www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key length and size
Erik Norgaard wrote: pair (n,e) and the private key can be respresented either as a pair (n,d) or in its Chinese Remainder Theorem form (CRT). The latter should be faster, but only applies for keys with more than two primefactors. Oh, I see, you use CRT to designate the key with the added speedup data. Yes, the Chinese Remainder Theorem is the speedup. But I believe it IS used for keys with only two prime factors, which is the usual case? Am I misunderstanding your terminology? The standard def for RSA is ( cleartext ^ E ) ^ D == cleartext mod p*q where D x E is 1 mod phi(p*q) I see only two primefactors: p and q. Over ten years ago I wrote an assembly language implementation of this (heavily cribbed from the RSAREF C) in which I used the CRT speedup. And I was getting a significant speedup from the CRT algorithm, and I only had two prime factors. There is a paper High-Speed RSA Implementation, TR 201 November 1994 (Acrobat .PDF, 497k) at http://www.rsasecurity.com/rsalabs/node.asp?id=2002 (last paper at bottom of page). In general the stuff at the RSA Labs site is pretty good quality. I am interested in your opinion of my idea about securely implementing a "session" protocol (as you put it). It seems to me that one could use an arbitrary number of transactions to put the key and data into the device, as long as they are masked with a session key. Even if the device is removed prematurely, the adversary can gain no advantage from any information input up to the point of the last operation. The last operation would be a "do it now" code with the session key. It seems to me this is just about as secure as your idempotent one-transaction model? -- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..." Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key generation on Windows
On Wed, Nov 08, 2000 at 12:00:57PM +0100, Frédéric Gariador wrote: > I'd like to use Openssl to generate a RSA key pair on Window NT. > > I wonder about some issues : > > - I use the -rand option to specify files used to seed the random number > generator. > According to the number of these file and their size, the number of > semi-random bytes loaded by openssl vary (this values is outputted > by the openssl command). > > What is a good value range for this number ? This depends on how unpredictable your files really are. If they contain actual randomness, then 1024 bytes is plenty. > - When the generation process ends, the following message is systematically > outputted: "unable to write 'random state'" > > - What does that mean ? > - Is that important ? There's a default file for randomness, which is used even without the -rand option: If environment variable RANDFILE exists, then the filename in RANDFILE is used; otherwise, if environment variable HOME is set, then file .rnd in directory $HOME is used; otherwise the file is .rnd in the current directory. Unless seeding was obviously insufficient, the applications try to write back to that file so that they have some random seeding the next time one of them is called. That warning message means that writing to the file determined as described above did not work, for whatever reasons -- maybe $HOME is set incorrectly. -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: RSA key generation on Windows
Thank you for your answer ! But it leads to another question :-) Do you know a reliable tools that permit to generate a file containing actual randomn numbers on Windows NT ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bodo Moeller Sent: vendredi 10 novembre 2000 09:21 To: [EMAIL PROTECTED] Subject: Re: RSA key generation on Windows On Wed, Nov 08, 2000 at 12:00:57PM +0100, Frédéric Gariador wrote: > I'd like to use Openssl to generate a RSA key pair on Window NT. > > I wonder about some issues : > > - I use the -rand option to specify files used to seed the random number > generator. > According to the number of these file and their size, the number of > semi-random bytes loaded by openssl vary (this values is outputted > by the openssl command). > > What is a good value range for this number ? This depends on how unpredictable your files really are. If they contain actual randomness, then 1024 bytes is plenty. > - When the generation process ends, the following message is systematically > outputted: "unable to write 'random state'" > > - What does that mean ? > - Is that important ? There's a default file for randomness, which is used even without the -rand option: If environment variable RANDFILE exists, then the filename in RANDFILE is used; otherwise, if environment variable HOME is set, then file .rnd in directory $HOME is used; otherwise the file is .rnd in the current directory. Unless seeding was obviously insufficient, the applications try to write back to that file so that they have some random seeding the next time one of them is called. That warning message means that writing to the file determined as described above did not work, for whatever reasons -- maybe $HOME is set incorrectly. -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA key from a file
On Sun, Dec 14, 2003, [EMAIL PROTECTED] wrote: > Hi.. > > I am using crypto library of openssl. I need to generate a RSA key using > RSA_generate_key() and then store the key into a file and later read it from a > file when I need it. > As far as my knowledge of openssl goes... I generate the key, store it in a file > using RSA_print_fp() which stores the key in a formatted fashion. Then if I > want to use it, I read the file again and parse the contents of the file to get > the key back. > No that's not the way to do it. There's no opposite of RSA_print_fp() which will takes its human readable output and convert back to an RSA structure. > Is there any other easy way to do it? Can I just export the key to a file and > import it back from the file ? Please let me know. > The PEM functions are one way to go. These can be used to encrypt the private key with a passphrase too, since its very sensitive data. Check out the PEM manual pages for more info. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: RSA Key exchange and FIPS compliance
> We use OpenSSL for encryption within our application. > I am now enhancing our application to become FIPS compliant. > The OpenSSL FIPS Security Policy lists RSA key wrapping and > key establishment as non-approved. But the policy states that > it is included when 80 to 150 bits of encryption strength are > used. So how do I provide a key exchange if I want FIPS compliance? TLS is FIPS approved if you only used FIPS-allowed algorithms within it. OpenSSL does this in FIPS mode. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA Key exchange and FIPS compliance
Gatfield, Geoffrey wrote: Hello, We use OpenSSL for encryption within our application. I am now enhancing our application to become FIPS compliant. The OpenSSL FIPS Security Policy lists RSA key wrapping and key establishment as non-approved. But the policy states that it is included when 80 to 150 bits of encryption strength are used. So how do I provide a key exchange if I want FIPS compliance? Any help is appreciated. Thanks Geoff If you look at the list of CMVP approved RSA implementations (http://csrc.nist.gov/cryptval/dss/rsaval.html) you will note that the OpenSSL FIPS Object Module, RSA cert #177, has as many or more "merit badges" than almost any other product. The FIPS 140-2 terminology is confusing to the uninitiated, among whom I include myself even after working this validation for five years. RSA encryption/decryption/key wrapping is not "Approved", instead it is classified as "Non-Approved, but allowed for use in FIPS 140-2 mode". RSA sign/verify is "Approved", and hence is listed with the Approved algorithms. You may use either in FIPS 140-2 mode. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: RSA Key exchange and FIPS compliance
This helps a lot. Thanks for the clarification. -Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Marquess Sent: Thursday, April 19, 2007 4:48 PM To: openssl-users@openssl.org Subject: Re: RSA Key exchange and FIPS compliance Gatfield, Geoffrey wrote: > > Hello, > > We use OpenSSL for encryption within our application. I am now > enhancing our application to become FIPS compliant. The OpenSSL FIPS > Security Policy lists RSA key wrapping and key establishment as > non-approved. But the policy states that it is included when 80 to 150 > bits of encryption strength are used. So how do I provide a key > exchange if I want FIPS compliance? > > > > Any help is appreciated. > > > > Thanks > > Geoff > If you look at the list of CMVP approved RSA implementations (http://csrc.nist.gov/cryptval/dss/rsaval.html) you will note that the OpenSSL FIPS Object Module, RSA cert #177, has as many or more "merit badges" than almost any other product. The FIPS 140-2 terminology is confusing to the uninitiated, among whom I include myself even after working this validation for five years. RSA encryption/decryption/key wrapping is not "Approved", instead it is classified as "Non-Approved, but allowed for use in FIPS 140-2 mode". RSA sign/verify is "Approved", and hence is listed with the Approved algorithms. You may use either in FIPS 140-2 mode. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA key generation problems in OpenSSH
Hi I am unable to provide u with exact answer. but i thought it relevent to reply u. because I have also worked on RSA api's Following are the command to generate rsa keys 1) openssl genrsa -out private.pem 1024 <- This generates a 1024 bit keypair, but both keys are held in a single file initially. 2) openssl rsa -in private.pem -pubout -out public.pem <-extracts the public key from private.pem. Further u can go through website http://www.madboa.com/geek/openssl/ I feel this website shall be very useful to u. Thanks Rafeeq On Mon, 28 Feb 2005 21:51:38 -0800 (PST), prakash babu <[EMAIL PROTECTED]> wrote: > Hello All, > > I am working on an IPF(Itanium Processor Family) HPUX machine. > Using the configure option > > hpux-ia64-cc would be the appropriate configure option while building > OpenSSL in this platform. > But I have problems with OpennSSH authentication when I use this > option. > > OpenSSH uses > libcrypto of OpenSSL to generate the RSA key pair. > > > Scenario 1 - SSH built using OpenSSL configured with hpux-ia64-cc > > i. Generate RSA key pair > #/usr/bin/ssh-keygen -t rsa1 > > ii. View the public key > #cat //.ssh/identity.pub > 1024 35 > > 132930209076564001780747579042635122330299057445902509467023000 > > 00349019205201074514728005030360980059713439703168643901029 > > 101753840270447636402448290262026362746390202877148500919047739 > [EMAIL PROTECTED] > > iii. Run the sshd daemon > #/opt/ssh_hpux-cc/sbin/sshd -o'protocol 1' -ddd -e > > iv. Run the client > #/opt/ssh_hpux-cc/bin/ssh -1 -l root -o > 'PreferredAuthentications="pubkey"' localhost -vvv > > The sshd daemon > rejects this key as a result the > client authentication fails > > The compiler options for hpux-ia64-cc > "hpux-ia64-cc","cc:-Ae +DD32 +O1 +Olit=all -z > -DB_ENDIAN::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT MD2_CHAR RC4_INDEX RC4_CHAR > DES_U > NROLL DES_RISC1 > DES_INT:asm/ia64-cpp.o:dlfcn:hpux-shared:+Z::.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", > > > Scenario 2 -SSH built using OpenSSL configured with hpux-cc > > i. Generate RSA key pair > #/usr/bin/ssh-keygen -t rsa1 > > ii. View the public key > #cat //.ssh/identity.pub > 1024 35 > > 1437122910944460067534870792490584153638875494206294171941680796472959390850506068660764130660092003114 > > 6511827709926115182557164733137352007577919492698063416540177245308126918665480672846829658795559358482 > > 1448512729384759808648867203588282392206887007723304276717097798871889974434155451797730883704857498211 > [EMAIL PROTECTED] > > iii. Run the sshd daemon > #/opt/ssh_hpux-cc/sbin/sshd -o'protocol 1' -ddd -e > > iv. Run the client > #/opt/ssh_hpux-cc/bin/ssh -1 -l root -o > 'PreferredAuthentications="pubkey"' localhost -vvv > > The sshd daemon > accepts this key as a result the > client authentication passes > > The Compiler options for hpux-cc are as follows : > > hpux-cc > "hpux-cc", "cc:-DB_ENDIAN -DBN_DIV2W -DMD32_XARRAY -Ae +ESlit > +O1 -z::(unknown)::-Wl,+s -ldld:BN_LLONG DES_PTR DES_UNROL > L > DES_RISC1::dl:hpux-shared:+Z::.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", > > My Analysis of the problem so far. > > 1. The problem occurs while creation of > n in the public key part of the rsa key > > n=p*q (where p and q are prime big numbers) > > 2 . The value of > dmax in the big number structure indicates the size of the big number > > 3. The following function returns the value of dmax > #define bn_expand(a,bits) ((bits+BN_BITS2-1))/BN_BITS2)) <= > (a)->dmax)? (a):bn_expand2((a),(bits)/BN_BITS2+1)) > In this macro dmax is calculated as (bits)/BN_BITS2+1 > > > OpenSSL configure option is hpux-ccdmax=(512)/32 +1 = 17 > > OpenSSL configure option is hpux-ia64-cc > dmax=(512)64 +1= 9 > > Is this change in the value of dmax causes the variation in > the public key. > > 4. The compiler options > SIXTY_FOUR_BIT and > asm/ia64-cpp.o in > hpux-ia64-cc causes this problem. When > SIXTY_FOUR_BIT is replaced by > BN_LLONG and the > asm/ia64-cpp.o option is removed then > hpux-ia64-cc configure option works fine. > > Please correct me if I am wrong ? > > Thanks, > Prakash > > > > > Do you Yahoo!? > Yahoo! Mail - Easier than ever with enhanced se
Re: RSA key material in BER format
On Wed, 13 Mar 2002 [EMAIL PROTECTED] wrote: > Hello, > > I am trying to use the OpenSSL library to pull the RSA key material from a > known RSA key pair. What I would like to get is the private key material, > the public modulus, and the exponent in BER or DER format. > > Any ideas, help in the right direction would be appreciated, Just look at the apps/rsa.c file, that could be interesting for you. Hello from a happy Chrysalis cards user! (VeriSign affiliate) -- Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5 - Connaîtriez-vous une adresse oû télécharger un mail bomber ? Ou bien si vous en avez un (assez simple), pouvez-vous me l' envoyer ? -+- Y.G. in Guide du Neuneu d'Usenet : NeunEu vA tOuT p3TeR -+- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA key size is 64 or 128?
> why I can't build certificate with one 64 or 128 bits size RSA key? Because it could be cracked almost immediately. :) You are probably confusing RSA keys (which are 1K 2K or 4K typically) with DES and RC4. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA key size is 64 or 128?
Rich Salz wrote: why I can't build certificate with one 64 or 128 bits size RSA key? Because it could be cracked almost immediately. :) Yes, but what's your point? ;-) Response to OP, Rich Salz knows at least as much as I do about this stuff -- Seriously, no smiley here -- independent of recommended key sizes, you at least need enough key length to support a block size plus random padding (see OAEP), or a hash length plus random pad (cf. PKCS) for digital signatures. For toy ciphers, for play, not intended for real work, try 512 bit RSA keys. For serious stuff, probably 1024, 1536, or 2048-bit keys. Read the FAQ at the RSALABS site, it's a good start. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA key generation: can exponent lengths be specified?
Hmm... 160-bit public exponent ... that is a little strange. It sounds like the requirement for a (relatively weak) Diffie-Hellman exponent, not an RSA exponent. I know of no weaknesses with using any of the small RSA encrypt exponents (such as 3, 17, 65537), as long as the random padding of PKCS# block-type 2 is properly done. Also, some software cannot handle RSA public exponents that are larger than 4 bytes. In fact, OpenSSL's RSA_generate_key() is one such function! - Original Message - From: "James Bishop" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 05, 2001 5:46 AM Subject: RSA key generation: can exponent lengths be specified? > Good morning, > > I need to generate RSA keys with specified lengths for a smart card > application. The keys should have a 1024-bit modulus, a 160-bit public > exponent, and a 1024-bit private exponent. Could some kind soul either > explain how to do this or point me at appropriate documentation? > > Also, I would like to know whether this difference in the public and > private exponent lengths reduces the security of the encryption. > > Thanking you, in advance > James Bishop __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: RSA key creation from an external source (i.e file)
> I need to create an RSA (or DSA) key structure in C++ program given the > fact that the key is stored in external file. This key will be the > public key used for the verification of the digital signature. I have > browsed the crypto(3) online documentation but I have found no easy way > of doing this. Could anyone recommend a solution? openssl x509 -in cert.pem -C -noout __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
