Re: bit-size necessary in the command: openssl req -newkey rsa:bits?
I’m sorry to disturb you again, but isn’t there anybody who knows the answer to my question? I'm thankful for everything that could help me. Best regards domi domi wrote: Hello, I have got a question concerning the command openssl req -newkey rsa:bits …. which I use for creating a self-signed certificate for my small private CA. Some time ago I used the command like this with OpenSSL 0.9.7g (on Suse 10.0): openssl req –x509 –newkey rsa –out cacert.pem –outform PEM As you can see I did it without giving the bit-size because of the following section in my openssl.cnf: [ req ] default_bits = 2048 A few days ago I wanted to built up my CA on a different computer (Suse 10.2 with OpenSSL 0.9.8d). I did everything as I was used to. But this time I had to add the bit-size although I used the default_bits option again in my openssl.cnf: openssl req -x509 –newkey rsa:2048 –out cacert.pem –outform PEM As you can see there is no real problem as long as everything works as I want but I would like to know why I have to add the bit-size with the new version of OpenSSL. Is it a feature/fault of the version? Can the same be observed with a newer version? (I know that I could test it on my own with a newer version but I don`t want to because everything works quiet fine right now.) Of course I took a look into the news and the changelog on http://www.openssl.org/news/news.html but I wasn’t able to find an answer for my question. So I hope that somebody in this forum can help me. Best regards domi -- View this message in context: http://www.nabble.com/bit-size-necessary-in-the-command%3A-openssl-req--newkey-rsa%3Abits--tf3790387.html#a10964297 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RSA library and block size
Hi at all, is it possible to change the OpenSSL RSA functions so that I can use a different - may be a variable - block size. At the moment the block size on the OpenSSL RSA functions depends on the length of the RSA key pair and the kind of padding (following PKCS#1 v1.5, which means 11 byte random data): key lenght block size available space 2024 bit256 byte245 byte 1024 bit128 byte105 byte 768 bit 96 byte 85 Normally, on symmetric encryption the block size _must_ be the same as the key lenght. But on asymmetric encryption methods - I think - the block size not depends on that restriction, or is there another point, which forces such a fixed block size? Many thanks in advance! Best regards, Philippe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: RSA library and block size
Hi at all, is it possible to change the OpenSSL RSA functions so that I can use a different - may be a variable - block size. At the moment the block size on the OpenSSL RSA functions depends on the length of the RSA key pair and the kind of padding (following PKCS#1 v1.5, which means 11 byte random data): key lenght block size available space 2024 bit256 byte245 byte 1024 bit128 byte105 byte 768 bit 96 byte 85 Normally, on symmetric encryption the block size _must_ be the same as the key lenght. But on asymmetric encryption methods - I think - the block size not depends on that restriction, or is there another point, which forces such a fixed block size? Many thanks in advance! Please accept my apologies for being totally blunt and not pulling any punches. You have no idea what you are doing and have no hope of producing any actual security, regardless of how good the libraries and algorithms you use are. Please pick up a good book on security algorithms and read it. Otherwise, you will repeat every mistake. The answer to your question is no, the block size is a fundamental characteristic of the way RSA works and failure to understand block size and padding in great detail makes it all but impossible to get any security out of RSA. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA library and block size
Hello, is it possible to change the OpenSSL RSA functions so that I can use a different - may be a variable - block size. At the moment the block size on the OpenSSL RSA functions depends on the length of the RSA key pair and the kind of padding (following PKCS#1 v1.5, which means 11 byte random data): key lenght block size available space 2024 bit256 byte245 byte 1024 bit128 byte105 byte 768 bit 96 byte 85 Normally, on symmetric encryption the block size _must_ be the same as the key lenght. Not exactly, for example: AES128: key: 16bytes, block: 16bytes AES192: key: 24bytes, block: 16bytes AES256: key: 32bytes, block: 16bytes DES3 : key: 24bytes, block: 8bytes and of course des which has key_len == block_len: DES : key: 8bytes, block: 8bytes But on asymmetric encryption methods - I think - the block size not depends on that restriction, or is there another point, which forces such a fixed block size? Amount of data which may be encrypted with RSA depends on algorithm. If you have private key (d,n) and public key (e,n) where n=p*q, where p and q are prime numbers. Encryption of plain P: C = P^e mod n Decryption of cipher C: P = C^d mod n As you see, you get always result as number from 0 to n-1 (modulo operation) and n is RSA key size. To be more specific, RSA operation is performed inside multiplicative group. 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 library and block size
* Marek Marcola wrote: * Philippe Stellwag wrote: is it possible to change the OpenSSL RSA functions so that I can use a different - may be a variable - block size. At the moment the block size on the OpenSSL RSA functions depends on the length of the RSA key pair and the kind of padding (following PKCS#1 v1.5, which means 11 byte random data): key lenght block size available space 2024 bit256 byte245 byte 1024 bit128 byte105 byte 768 bit 96 byte 85 Normally, on symmetric encryption the block size _must_ be the same as the key lenght. Not exactly, for example: AES128: key: 16bytes, block: 16bytes AES192: key: 24bytes, block: 16bytes AES256: key: 32bytes, block: 16bytes DES3 : key: 24bytes, block: 8bytes and of course des which has key_len == block_len: DES : key: 8bytes, block: 8bytes Okay, thanks for that correction! But on asymmetric encryption methods - I think - the block size not depends on that restriction, or is there another point, which forces such a fixed block size? Amount of data which may be encrypted with RSA depends on algorithm. If you have private key (d,n) and public key (e,n) where n=p*q, where p and q are prime numbers. Encryption of plain P: C = P^e mod n Decryption of cipher C: P = C^d mod n As you see, you get always result as number from 0 to n-1 (modulo operation) and n is RSA key size. To be more specific, RSA operation is performed inside multiplicative group. Okay, that means that plain P (interpreted as an integer figure) must be smaller than n, so that it is between the multiplicative group, like the following example: n=3*5 phi(n)=(3-1)*(5-1)=8 e=3 d=(4*8+1)/3=11 (4 is choosen by me = see Euler) P=2 (should work) C=2^3 mod 15=8 P=8^11 mod 15=2 (that's it) P=41 (not between the multiplicative group (because 15) and so not unique = shouldn't work) C=41^3 mod 15=11 P=11^11 mod 15=(believe me (-:)=11 (not the same integer as 41, but the same in the multiplicative group: 41 mod 15 = 11 mod 15) Okay, that's clear! But can I use e.g. a 1024 bit key pair with a block size of 116 byte, that is not depending on the problem shown above, isn't it?! What is the security reason, why not to do this? I have a small-sized EEPROM with 116 bytes and I try to use a key pair with 928 bit length (= 116 byte block size and 105 byte for unencrypted user data). Thanks a lot for that posting! Philippe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: RSA library and block size
But can I use e.g. a 1024 bit key pair with a block size of 116 byte, that is not depending on the problem shown above, isn't it?! What is the security reason, why not to do this? That would seriously weaken the security properties. http://en.wikipedia.org/wiki/RSA Read the section on padding schemes. An attacker than can predict the plaintext can break the encryption. A 116 byte plaintext may not be sufficiently unpredictable to preserve the level of security you expect from a 1,024 bit key. (RSA is 100% deterministic.) RSA cannot be used securely except by experts (because it has too many internal weaknesses that must be carefully worked around by the surrounding system). I strongly urge you to either use a pre-designed scheme around RSA or to employ an expert. There are simply too many ways you can go wrong. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA library and block size
* David Schwartz wrote: But can I use e.g. a 1024 bit key pair with a block size of 116 byte, that is not depending on the problem shown above, isn't it?! What is the security reason, why not to do this? That would seriously weaken the security properties. http://en.wikipedia.org/wiki/RSA Read the section on padding schemes. An attacker than can predict the plaintext can break the encryption. A 116 byte plaintext may not be sufficiently unpredictable to preserve the level of security you expect from a 1,024 bit key. (RSA is 100% deterministic.) Oh yes, RSA is a deterministic encryption method. To protect RSA from a known- plaintext-attack, a random padding string is used, right? How secure is it or do you say, for 116 byte disc space I have to use a probabilistic encryption system, like ElGamal. But OpenSSL cannot ElGamal encryption. Hmm... RSA cannot be used securely except by experts (because it has too many internal weaknesses that must be carefully worked around by the surrounding system). I strongly urge you to either use a pre-designed scheme around RSA or to employ an expert. There are simply too many ways you can go wrong. What do you suggest? I want to store some encrypted data on this 116 byte sized disc. I want to use an asymmetric encryption system with only one key pair for many such 116 byte discs, used by many people. Think on two-factor- authentication with a smartcard without cryptographic functions (a passive storage). Hmm, I think I have to use some probabilistic (asymmetric) encryption method... Thanks a lot! Philippe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA library and block size
Hello, * Philippe Stellwag wrote: is it possible to change the OpenSSL RSA functions so that I can use a different - may be a variable - block size. At the moment the block size on the OpenSSL RSA functions depends on the length of the RSA key pair and the kind of padding (following PKCS#1 v1.5, which means 11 byte random data): key lenght block size available space 2024 bit256 byte245 byte 1024 bit128 byte105 byte 768 bit 96 byte 85 Normally, on symmetric encryption the block size _must_ be the same as the key lenght. Not exactly, for example: AES128: key: 16bytes, block: 16bytes AES192: key: 24bytes, block: 16bytes AES256: key: 32bytes, block: 16bytes DES3 : key: 24bytes, block: 8bytes and of course des which has key_len == block_len: DES : key: 8bytes, block: 8bytes Okay, thanks for that correction! But on asymmetric encryption methods - I think - the block size not depends on that restriction, or is there another point, which forces such a fixed block size? Amount of data which may be encrypted with RSA depends on algorithm. If you have private key (d,n) and public key (e,n) where n=p*q, where p and q are prime numbers. Encryption of plain P: C = P^e mod n Decryption of cipher C: P = C^d mod n As you see, you get always result as number from 0 to n-1 (modulo operation) and n is RSA key size. To be more specific, RSA operation is performed inside multiplicative group. Okay, that means that plain P (interpreted as an integer figure) must be smaller than n, so that it is between the multiplicative group, like the following example: n=3*5 phi(n)=(3-1)*(5-1)=8 e=3 d=(4*8+1)/3=11 (4 is choosen by me = see Euler) P=2 (should work) C=2^3 mod 15=8 P=8^11 mod 15=2 (that's it) P=41 (not between the multiplicative group (because 15) and so not unique = shouldn't work) C=41^3 mod 15=11 P=11^11 mod 15=(believe me (-:)=11 (not the same integer as 41, but the same in the multiplicative group: 41 mod 15 = 11 mod 15) or 45 is in the equivalency class of 11 But can I use e.g. a 1024 bit key pair with a block size of 116 byte, that is not depending on the problem shown above, isn't it?! What is the security reason, why not to do this? Of course you can, you can use even block size of 128 (but encoded number must be less than n). Padding is for proper randomizing data to guard against some cryptographic attacks such adaptive chosen-plaintext attack. But this depends on situation, in PKCS#1 when private key is used padding is not used for randomizing but rather to extend data to proper (key) length (additional space if filled with 0xff). When public key is used then padding randomizes clear text data (instead of 0xff - random, non zero, data is generated). In PKCS#1 first two bytes informs of key block: 0x0001 - private 0x0002 - public and this should be checked after RSA decrypt. This guards against next type of attack. But all this depends on your environment. There are many padding algorithms, not only PKCS#1, I think that there is possible to randomize for example 128 bytes plaintext and not extending length with some already known information. But of course this will not be compatible with existing systems. I read in some book about RSA-CBC scheme, I do not remember know if in this scheme padding is used or not. Or maybe you can send your data in two smaller RSA encrypted messages ? 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 library and block size
* Marek Marcola wrote:
[...]
Or maybe you can send your data in two smaller RSA encrypted
messages ?
I just want to store some authentication data - a username, group and
date - on a token, which only offers a passive storage (116 byte
EEPROM) without any cryptografic functions, to save a secret
(normally a private key) from outside access. So this authentication
data must be encrypted to prevent unauthorized modification, because
every - maybe unauthorized - person can read and write on this
token. This token should used for a two-factor-autentication
process with an additional password or pin. So, I want to use one
private RSA key the centrally sign this data. Decentral, I intend to
verify the RSA signature with the concerning public key. Is the
verification process successfully done, than the information stored
on the token are valid.
The problem is that deterministic encryption methods (like RSA)
offers the possibility of an {known, choosen}-plaintext-attack,
because the users (partial) know their own authentication data!
My questions are very simple: Is the RSA crypto-system with random
padding (e.g. default PKCS#1 v1.5 or OAEP) strong enough to
implement such a solution or is my concept totally insecure and I
should use e.g. an ElGamal encryption system?
Best regards,
Philippe
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
non-blocking IO and revocation checking
From a brief look at the cert validation code, it appears that there's no way to do non-blocking IO while performing on-line revocation checks, e.g. querying a CDP or an OCSP responder. Is that correct? Specifically, I see in ssl_cert.c a call is made to X509_verify_cert(), or a user-supplied verification callback. It looks like X509_verify_cert() only checks CRLs, and only CRLs that have been previously stored in the context. So, no CDP lookups. Further, it looks like if a user-supplied callback is provided that does a CDP lookup, there's no way for the callback to return a would-block error, or for the handshake to be retried once the revocation data is available. Is that correct? b.c. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: non-blocking IO and revocation checking
On Mon, Jun 04, 2007, Brian Craft wrote: From a brief look at the cert validation code, it appears that there's no way to do non-blocking IO while performing on-line revocation checks, e.g. querying a CDP or an OCSP responder. Is that correct? Specifically, I see in ssl_cert.c a call is made to X509_verify_cert(), or a user-supplied verification callback. It looks like X509_verify_cert() only checks CRLs, and only CRLs that have been previously stored in the context. So, no CDP lookups. Further, it looks like if a user-supplied callback is provided that does a CDP lookup, there's no way for the callback to return a would-block error, or for the handshake to be retried once the revocation data is available. Is that correct? Currently no. Adding support via special return codes is not that hard to do but would cause problems for existing applications. The reason is that they would not know how to handle the condition. It could behave in a manner similar to the existing non-blocking I/O but it would be via a different socket (e.g. the one downloading the CRL or performing OCSP). 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 library and block size
Hello,
I just want to store some authentication data - a username, group and
date - on a token, which only offers a passive storage (116 byte
EEPROM) without any cryptografic functions, to save a secret
(normally a private key) from outside access. So this authentication
data must be encrypted to prevent unauthorized modification, because
every - maybe unauthorized - person can read and write on this
token.
Maybe I do not understand this correctly, but if you want to encrypt
some data with RSA 1024 bit key then you will get 128 bytes of output
ciphertext. It is not important what padding scheme you will use
(or even no padding at all) you should get 128 bytes output from
modular exponentation process. So you will not be able to store
this on your token. Or I really miss something :-)
This token should used for a two-factor-autentication
process with an additional password or pin. So, I want to use one
private RSA key the centrally sign this data. Decentral, I intend to
verify the RSA signature with the concerning public key. Is the
verification process successfully done, than the information stored
on the token are valid.
Ok, but in this case token can be copied without problem.
In general this works like mini-certificate but so called
certificate authentication requires not only certificate
but corresponding private key too. Verification process must
prove that peer has secret private key and then information
from certificate is checked.
Or maybe token has some unique information (like serial number
stored in not writable memory) which can be inserted in user
authentication data (which is signed) to limit copying.
The problem is that deterministic encryption methods (like RSA)
offers the possibility of an {known, choosen}-plaintext-attack,
because the users (partial) know their own authentication data!
In this case I think this is not a problem because this is data
signing process. In PKCS1 when you sign data with private key
there is NO random information generated. All message that is
encrypted with private key is known. For example if you want to sign
some message you calculate its digest (hash, SHA1 for example),
next you build ASN.1 DigestInfo structure, and pad this with PCKS1.
But this padding only adds in front of DigestInfo known block and you
get something like that:
0x0001.FF00DigestInfo
and this is encrypted with private key.
As you see, there is no random information in this case.
My questions are very simple: Is the RSA crypto-system with random
padding (e.g. default PKCS#1 v1.5 or OAEP) strong enough to
implement such a solution or is my concept totally insecure and I
should use e.g. an ElGamal encryption system?
As I told before, signing with PKCS#1 does not implement random
padding but static.
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
