RE: Aes-256 /testing of AES_cbc_encrypt
Hi, I went through FIPS-197 for AES. Now if I want to test void AES_cbc_encrypt(const unsigned char *in, unsigned char *out, const unsigned long length, const AES_KEY *key, unsigned char *ivec, const int enc) function. How should I test this function? Regards, Jaya. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Monday, September 04, 2006 4:51 PM To: openssl-users@openssl.org Subject: Re: Aes-256 Hello, I want to test AES-256 encryption and decryption. And also SH-512 hashing functionality in SSL. Pls can any one tell me how do I do it? If you want to check correctness of your implementation/OpenSSL API you may download FIPS-197 (for AES) and FIPS-180 (for SHA1/256/384/512) and use test vectors from this documents. 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: Securing passwords
David Irvine wrote: [...] Many thanks for replying - your right I am a bit off topic (and I hope I don't need a surgeon for being so ;-) ) but I suppose it is slightly related to the securing of info. Yes, I'll reply on the list till someone complains. I think you are correct in your assumption for some readers. I am thinking along the lines of a public reader i.e. one which anybody can finger swipe to get access to data and therefore the digitised stream may be sent somewhere. I am using the premise that any non encrypted data stream on a PC can be captured. My thoughts were that if it were possible to have an encrypted (PKI) copy of this stream that only the server could decrypt (if there was a server) or an application could decrypt, can such devices create a secure link between them and a server or application to transmit this, and if so can it be easily compromised (everything can to some degree I suppose). If it's only the data between the reader and computer that can be captured, the method outlined above (using the fingerprint as a PIN for a smartcard chip) should be secure under the usual assumptions concerning key size etc. Just remember, most probably it's not really encryption you want, it's authentication! Encryption can help but it's not the only way. The problems start if the bad guys start using screwdrivers or are otherwise fiddeling around with the reader (see for example http://ds.ccc.de/080/finger if you can read german) or the computer. If computer and reader themselves are not considered secure you'll probably have to go for something like TPM to increase the security. Apart from that what is the most effective way of entering a password to stop keyloggers I have been racking my brain thinking of a defeat for them but can't come up with one yet although I'm sure there is an answer somewhere. [...] IMHO the most efficient way currently is to use a class 2 smartcard reader. Whether to use a fingerprint sensor (integrated to the reader!) or a PIN (entered on the pinpad of the reader!) to unlock signature generation is more or less a matter of personal taste or other circumstances of your application. For example I'd prefer a fingerprint reader if it's easy for an attacker to install a web cam to watch the pinpad. On the other hand, if you can enter the PIN in some closet with no public access I'd prefer the pinpad. Of course both versions can still be defeated by installing keyloggers inside the reader device or capturing the PIN/fingerprint using known techniques, but you have better chances to defend against this. My concern is that I have a p2p app which needs AES / RSA etc. and therefore a pass at some time - can't use a server so kerberos / single pass etc. is a no goer. Hmm, maybe *encryption* should be handled between the peers using the peer's keys and *authentication* can be done by a smartcard/class 2 reader? This seems to take care of your problems if the peers themselves are secure. Another approach I've seen with homebanking (less secure than a class 2 reader/smartcard but probably easier to implement) is to use the mouse to enter a PIN on a screen pinpad, which is at a random position on the screen and/or the keys are randomly distributed. This is still vulnerable to webcams but the image quality has to be much better if you use a tiny cursor... [...] So far 1: A bio reader that stores a pass seems to be quite good (although personalised) No, a stored password is not really good, since the transmission can be intercepted. By the way, are you familliar with smartcard technology? 2: A bio reader that can encrypt and secure a link between it and authority mechanism (server or app) would be better - not personalised. 3: A passphrase - well this is the issue - we can make them stronger by running through pbkdf2 etc. but it's the entering that's not right (insecure). 4. Biometric sensors can be fooled considerably easier than realized in public perception (BTW, the same thing is probably true for encryption in general). Biometric sensors are still to be considered somewhat experimental, especially if the reader devices are cheap! Pinpads have their own risks, but at least those are more publicly known (or are they?). Problem software or hardware loggers (think worst case - hardware) can read anything we input to screen mouse or keyboard so 1: Are they easy to detect (NO!) 2: Can they be fooled by cut paste etc. / NO many read clipboard But cut'n paste is still vulnerable to webcams watching the screen! So assuming somebody can SEE everything we type or move the mouse to (images etc.) what can be done ? 1. Use inputs that cannot be seen so easily (the biometric approach) 2. Make sure the input cannot be seen (the pinpad reader approach) One very important thing to remember: There is *no* perfect security in real life! Just forget what your insurance agent is always telling you! ;) And that's the
Problem with DER formatted file when downloaded thru HTTP
Hi Team, I am seeing a problem with DER formatted file. I downloaded the DER formatted file (crl file) using a standard http client application. But I could not open that file and it is saying The file is invalid for use as the following: Certificate Revocation List while trying to open it. But with same http client application, I could download the Base-64 formatted file successfully and I could open the file successfully. After that, I used the load_crl() function. That's also success. But for the DER formatted file, I am seeing an issue in opening the file and thereby load_crl() is failing since it is a invalid crl file. So my question is: After downloading the DER formatted file, should I need to append any particular EOF (End Of File) character? If so, what is that? Please let me know your thoughts on end of file character for DER formatted file. Thousands of thanks to you, -Surendra The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Question reagrding OpenSSL recent security advisory
Hello, I have read the advisory an I am a bit puzzled regarding the there are CAs using exponent 3 in wide use comment, I have tried to check and could not found any CA using this exponent, all the CAs I have seen are using 0x10001 (CAs I have generate by OpenSSL using default values, world wide trusted CAs such as VeriSign and Thawte etc..), I understand that specifying CAs using exponent 3 will give specific targets to malicious people and that is defiantly not a good idea, how ever I would like to try and better understand the range of the problem, are only old CAs using exponent 3 ? Could anyone elaborate some on this? Regards, Hagai,
Query regarding AES support in Open SSL
Hi, I am using keytool command to generate the certificates, currently i am using RSA algorithm. We are planning to change this to AES, does Open SSL support AES? If yes can i use it with keytool command. Thanks Bharath
RE: Query regarding AES support in Open SSL
Yes OpenSSL supports AES. Regards, Jaya From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of V, Bharath (Bharath)Sent: Wednesday, September 06, 2006 3:08 PMTo: 'openssl-users@openssl.org'Subject: Query regarding AES support in Open SSL Hi, I am using keytool command to generate the certificates, currently i am using RSA algorithm. We are planning to change this to AES, does Open SSL support AES? If yes can i use it with keytool command. Thanks Bharath
RE: Aes-256 /testing of AES_cbc_encrypt
Hello, I went through FIPS-197 for AES. Now if I want to test void AES_cbc_encrypt(const unsigned char *in, unsigned char *out, const unsigned long length, const AES_KEY *key, unsigned char *ivec, const int enc) function. How should I test this function? For test vectors you may look in test/evptests.txt in OpenSSL source. For example if you will have test line like: AES-128-CBC:2B7E151628AED2A6ABF7158809CF4F3C:000102030405060708090A0B0C0D0E0F:6BC1BEE22E409F96E93D7E117393172A:7649ABAC8119B246CEE98E9B12E9197D then to test this from command line you may run: $ perl -e 'print pack(H*,6BC1BEE22E409F96E93D7E117393172A)' | \ openssl enc -e -aes-128-cbc \ -K 2B7E151628AED2A6ABF7158809CF4F3C \ -iv 000102030405060708090A0B0C0D0E0F | \ perl -e '$a=STDIN; print unpack(H*,$a), \n' to get: 7649abac8119b246cee98e9b12e9197d8964e0b149c10b7b682e6e39aaeb731c and of course if you run: $ perl -e 'print pack(H*,7649abac8119b246cee98e9b12e9197d8964e0b149c10b7b682e6e39aaeb731c)'|\ openssl enc -d -aes-128-cbc \ -K 2B7E151628AED2A6ABF7158809CF4F3C \ -iv 000102030405060708090A0B0C0D0E0F | \ perl -e '$a=STDIN; print unpack(H*,$a), \n' you will get: 6bc1bee22e409f96e93d7e117393172a The same results you should get using AES_cbc_encrypt() but you should be aware that padding is not removed by this function when you decrypt data. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Retrieving certificate data
Hi, I have to retrieve data from a client certificate (on a smart card) My code: $cert = openssl_x509_parse($_SERVER['SSL_CLIENT_CERT']); echo($cert['subject']['CN']); if I run it in local it works, otherwise on remote server nothing is printed out. Any idea? Thanks -- View this message in context: http://www.nabble.com/Retrieving-certificate-data-tf2225542.html#a6167169 Sent from the OpenSSL - User forum at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question reagrding OpenSSL recent security advisory
Hello, I have read the advisory an I am a bit puzzled regarding the there are CAs using exponent 3 in wide use comment, I have tried to check and could not found any CA using this exponent, all the CA’s I have seen are using 0x10001 (CA’s I have generate by OpenSSL using default values, world wide trusted CA’s such as VeriSign and Thawte etc..), I understand that specifying CA’s using exponent 3 will give specific targets to malicious people and that is defiantly not a good idea, how ever I would like to try and better understand the range of the problem, are only old CA’s using exponent 3 ? Could anyone elaborate some on this? Look at: http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Is there any API available to convert the DER formatted file to Base64 formatted file?
Hi Team, Is there any API available in OPENSSL to convert the DER formatted file to Base64 formatted file? Please let me know your thoughts. Thank you. -Suren The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Aes-256 /testing of AES_cbc_encrypt
Thank you very much for the quick reply. Regards, Jaya. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Wednesday, September 06, 2006 3:31 PM To: openssl-users@openssl.org Subject: RE: Aes-256 /testing of AES_cbc_encrypt Hello, I went through FIPS-197 for AES. Now if I want to test void AES_cbc_encrypt(const unsigned char *in, unsigned char *out, const unsigned long length, const AES_KEY *key, unsigned char *ivec, const int enc) function. How should I test this function? For test vectors you may look in test/evptests.txt in OpenSSL source. For example if you will have test line like: AES-128-CBC:2B7E151628AED2A6ABF7158809CF4F3C:000102030405060708090A0B0C0 D0E0F:6BC1BEE22E409F96E93D7E117393172A:7649ABAC8119B246CEE98E9B12E9197D then to test this from command line you may run: $ perl -e 'print pack(H*,6BC1BEE22E409F96E93D7E117393172A)' | \ openssl enc -e -aes-128-cbc \ -K 2B7E151628AED2A6ABF7158809CF4F3C \ -iv 000102030405060708090A0B0C0D0E0F | \ perl -e '$a=STDIN; print unpack(H*,$a), \n' to get: 7649abac8119b246cee98e9b12e9197d8964e0b149c10b7b682e6e39aaeb731c and of course if you run: $ perl -e 'print pack(H*,7649abac8119b246cee98e9b12e9197d8964e0b149c10b7b682e6e39aaeb7 31c)'|\ openssl enc -d -aes-128-cbc \ -K 2B7E151628AED2A6ABF7158809CF4F3C \ -iv 000102030405060708090A0B0C0D0E0F | \ perl -e '$a=STDIN; print unpack(H*,$a), \n' you will get: 6bc1bee22e409f96e93d7e117393172a The same results you should get using AES_cbc_encrypt() but you should be aware that padding is not removed by this function when you decrypt data. 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: [SECURITY] OpenSSL 0.9.8c and 0.9.7k released
This release fixes an important security vulnerability which could allow RSA Signature Forgery, CVE-2006-4339. Please see http://www.openssl.org/news/secadv_20060905.txt I could see the patch available in the location http://www.openssl.org/news/patch-CVE-2006-4339.txt is been updated with removal of unwanted code lines. Will these changes be commited to the OpenSSL releases 0.9.7k and 0.9.8c. If so, when will the tar-balls be available. --Haridharan. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Description of the X509 object
Hello, I want to implement my own certificate storage. But I can't find information about the OpenSSL X509 and the X509_STORE object. But this is need to feed OpenSSL with the certs and key's of my Certificate storage. Have anybody some documentatoion about these object's? Thanks. smime.p7s Description: S/MIME Cryptographic Signature
Re: Query regarding AES support in Open SSL
I am using keytool command to generate the certificates, currently i am using RSA algorithm. We are planning to change this to AES You can't do that. (Well, actually, you can, but it means that anyone who can verify the certificate can also generate their own counterfeit that is impossible to detect. You probably need to read some intro material on crypto. /r$ -- SOA Appliances Application Integration Middleware __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Query regarding AES support in Open SSL
V, Bharath (Bharath) wrote: I am using keytool command to generate the certificates, currently i am using RSA algorithm. We are planning to change this to AES, does Open SSL support AES? If yes can i use it with keytool command. RSA is an asymmetric algorithm, which is used to establish a channel by which symmetric keys can be exchanged in confidence. AES is a symmetric algorithm, which is used after the key exchange has taken place. They are not interchangeable. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question reagrding OpenSSL recent security advisory
On Wed, Sep 06, 2006, Hagai Yaffe wrote: I have read the advisory an I am a bit puzzled regarding the there are CAs using exponent 3 in wide use comment, I have tried to check and could not found any CA using this exponent, all the CA's I have seen are using 0x10001 (CA's I have generate by OpenSSL using default values, world wide trusted CA's such as VeriSign and Thawte etc..), I understand that specifying CA's using exponent 3 will give specific targets to malicious people and that is defiantly not a good idea, how ever I would like to try and better understand the range of the problem, are only old CA's using exponent 3 ? Could anyone elaborate some on this? I don't want to name names here but a brief study I did revealed 8 public CA root certificates which used exponent 3. 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]
Including attributes in the signed certificate
Hi ! I'm trying to include attributes/fields in a signed certificate. I've first issued a CSR with some extra attributes in it, here's what the CSR looks like with openssl req -in test.csr -text -noout : Certificate Request: Data: Version: 0 (0x0) Subject: O=TEST, OU=Support, CN=TEST/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: dsaEncryption DSA Public Key: pub: (snip) P: (snip) Q: (snip) G: (snip) Attributes: countryName :FR localityName :Paris uidNumber:4321 gidNumber:1234 uid :test Signature Algorithm: dsaWithSHA1 (snip) I'm very happy so far, as I the attributes/fields countryName, uid, uidNumber, ... I added in the [req_attribute] of the default openssl.cnf file, along with their respective OIDs in the [new_oids] section. But, when I sign the certificate request with that same openssl.cnf file, either with openssl ca or with openssl x509, the produced certificate does not include those attributes, as shown by openssl x509 -text -in test.crt -noout Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=TEST CA, O=TEST/[EMAIL PROTECTED] Validity Not Before: Sep 6 11:09:06 2006 GMT Not After : Sep 7 11:09:06 2006 GMT Subject: O=TEST, OU=Support, CN=TEST/[EMAIL PROTECTED]Subject Public Key Info: Public Key Algorithm: dsaEncryption DSA Public Key: pub: (snip) P: (snip) Q: (snip) G: (snip) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 19:88:DF:ED:6C:82:86:BA:91:81:AA:1A:A4:55:A7:5C:20:7B:5A:62 X509v3 Authority Key Identifier: keyid:CF:A8:E1:B1:BD:5C:B2:55:9B:20:F5:44:8E:36:D2:F4:E6:E9:10:FF Signature Algorithm: sha1WithRSAEncryption (snip) Would anyone help me ? or at least tell me where I got wrong ? Thanks for any kind of help, Hubert, UNIX is user friendly. It's just selective about who its friends are. Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de ses destinataires. Toute utilisation ou diffusion, même partielle, non autorisée est interdite. Tout message électronique est susceptible d'altération. Brink's décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'avertir l'expéditeur. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized use or disclosure, either whole or partial is prohibited. E-mails are susceptible to alteration. Brink's shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. * __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
PFX to PEM
Hi, how is PFX to PEM converting done? I know of the command openssl --pkcs12 --in foo.pfx --out foo.pem but what is done internally? Just converting to base64? Thanks for hints. --sk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Including attributes in the signed certificate
There is one more problem with attributes and official CA's. If you are your own CA, it makes a big difference (less trust around in the world - but you can enforce any attribute verification policy that you choose yo). Atttributes are added at the time of certification (good - so they can't be maliciously changed/removed/added later), but currently CA's do NOT verify them (bad - crap placed in by the identity owner is still crap). Thus, you can prove that you are Hubert - and add a whole bunch of stuff about you (the tallest man in Germany, undercover assistant of UN Secretary General, whatever). Resulting cert will contain a mix of true statements with something uncertain. A solution can be Attribute Certificate. I dont know if it makes sense to you - running your own CA you're free to do what's right regardless of what VeriSign is doing. Sorry I didn't answer your question - somebody more knowledgeable about OpenSSL will explain why it exhibits what I consider a bug (whatever is placed in the CSR must be signed IMHO). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quarantel, Hubert Sent: Wednesday, September 06, 2006 08:46 To: openssl-users@openssl.org Subject: Including attributes in the signed certificate Hi ! I'm trying to include attributes/fields in a signed certificate. I've first issued a CSR with some extra attributes in it, here's what the CSR looks like with openssl req -in test.csr -text -noout : Certificate Request: Data: Version: 0 (0x0) Subject: O=TEST, OU=Support, CN=TEST/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: dsaEncryption DSA Public Key: pub: (snip) P: (snip) Q: (snip) G: (snip) Attributes: countryName :FR localityName :Paris uidNumber:4321 gidNumber:1234 uid :test Signature Algorithm: dsaWithSHA1 (snip) I'm very happy so far, as I the attributes/fields countryName, uid, uidNumber, ... I added in the [req_attribute] of the default openssl.cnf file, along with their respective OIDs in the [new_oids] section. But, when I sign the certificate request with that same openssl.cnf file, either with openssl ca or with openssl x509, the produced certificate does not include those attributes, as shown by openssl x509 -text -in test.crt -noout Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=TEST CA, O=TEST/[EMAIL PROTECTED] Validity Not Before: Sep 6 11:09:06 2006 GMT Not After : Sep 7 11:09:06 2006 GMT Subject: O=TEST, OU=Support, CN=TEST/[EMAIL PROTECTED]Subject Public Key Info: Public Key Algorithm: dsaEncryption DSA Public Key: pub: (snip) P: (snip) Q: (snip) G: (snip) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 19:88:DF:ED:6C:82:86:BA:91:81:AA:1A:A4:55:A7:5C:20:7B:5A:62 X509v3 Authority Key Identifier: keyid:CF:A8:E1:B1:BD:5C:B2:55:9B:20:F5:44:8E:36:D2:F4:E6:E9:10:FF Signature Algorithm: sha1WithRSAEncryption (snip) Would anyone help me ? or at least tell me where I got wrong ? Thanks for any kind of help, Hubert, UNIX is user friendly. It's just selective about who its friends are. Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de ses destinataires. Toute utilisation ou diffusion, même partielle, non autorisée est interdite. Tout message électronique est susceptible d'altération. Brink's décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'avertir l'expéditeur. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized use or disclosure, either whole or partial is prohibited. E-mails are susceptible to alteration. Brink's shall not be liable for the message if altered, changed or falsified. If you are not
Re: Securing passwords
Bernhard Froehlich wrote: David Irvine wrote: [...] Many thanks for replying - your right I am a bit off topic (and I hope I don't need a surgeon for being so ;-) ) but I suppose it is slightly related to the securing of info. Yes, I'll reply on the list till someone complains. I think you are correct in your assumption for some readers. I am thinking along the lines of a public reader i.e. one which anybody can finger swipe to get access to data and therefore the digitised stream may be sent somewhere. I am using the premise that any non encrypted data stream on a PC can be captured. My thoughts were that if it were possible to have an encrypted (PKI) copy of this stream that only the server could decrypt (if there was a server) or an application could decrypt, can such devices create a secure link between them and a server or application to transmit this, and if so can it be easily compromised (everything can to some degree I suppose). If it's only the data between the reader and computer that can be captured, the method outlined above (using the fingerprint as a PIN for a smartcard chip) should be secure under the usual assumptions concerning key size etc. Just remember, most probably it's not really encryption you want, it's authentication! Encryption can help but it's not the only way. The problems start if the bad guys start using screwdrivers or are otherwise fiddeling around with the reader (see for example http://ds.ccc.de/080/finger if you can read german) or the computer. If computer and reader themselves are not considered secure you'll probably have to go for something like TPM to increase the security. Apart from that what is the most effective way of entering a password to stop keyloggers I have been racking my brain thinking of a defeat for them but can't come up with one yet although I'm sure there is an answer somewhere. [...] IMHO the most efficient way currently is to use a class 2 smartcard reader. Whether to use a fingerprint sensor (integrated to the reader!) or a PIN (entered on the pinpad of the reader!) to unlock signature generation is more or less a matter of personal taste or other circumstances of your application. For example I'd prefer a fingerprint reader if it's easy for an attacker to install a web cam to watch the pinpad. On the other hand, if you can enter the PIN in some closet with no public access I'd prefer the pinpad. Of course both versions can still be defeated by installing keyloggers inside the reader device or capturing the PIN/fingerprint using known techniques, but you have better chances to defend against this. My concern is that I have a p2p app which needs AES / RSA etc. and therefore a pass at some time - can't use a server so kerberos / single pass etc. is a no goer. Hmm, maybe *encryption* should be handled between the peers using the peer's keys and *authentication* can be done by a smartcard/class 2 reader? This seems to take care of your problems if the peers themselves are secure. Another approach I've seen with homebanking (less secure than a class 2 reader/smartcard but probably easier to implement) is to use the mouse to enter a PIN on a screen pinpad, which is at a random position on the screen and/or the keys are randomly distributed. This is still vulnerable to webcams but the image quality has to be much better if you use a tiny cursor... [...] So far 1: A bio reader that stores a pass seems to be quite good (although personalised) No, a stored password is not really good, since the transmission can be intercepted. By the way, are you familliar with smartcard technology? 2: A bio reader that can encrypt and secure a link between it and authority mechanism (server or app) would be better - not personalised. 3: A passphrase - well this is the issue - we can make them stronger by running through pbkdf2 etc. but it's the entering that's not right (insecure). 4. Biometric sensors can be fooled considerably easier than realized in public perception (BTW, the same thing is probably true for encryption in general). Biometric sensors are still to be considered somewhat experimental, especially if the reader devices are cheap! Pinpads have their own risks, but at least those are more publicly known (or are they?). Problem software or hardware loggers (think worst case - hardware) can read anything we input to screen mouse or keyboard so 1: Are they easy to detect (NO!) 2: Can they be fooled by cut paste etc. / NO many read clipboard But cut'n paste is still vulnerable to webcams watching the screen! So assuming somebody can SEE everything we type or move the mouse to (images etc.) what can be done ? 1. Use inputs that cannot be seen so easily (the biometric approach) 2. Make sure the input cannot be seen (the pinpad reader approach) One very important thing to remember: There is *no* perfect security in real life! Just forget
Trouble building 0.9.7k shared libraries
Using Cygwin I am trying to build 0.9.7k with shared libraries: $ ./config --prefix=/tmp/bob shared $ make depend $ make test The above completes no problem but when I do the 'make install' I get the followng errors: [snip] installing libcrypto.dll.a cp: cannot stat `cygcrypto-0.9.7.dll.a': No such file or directory chmod: cannot access `/tmp/bob/bin/cygcrypto-0.9.7.dll.a.new': No such file or directory mv: cannot stat `/tmp/bob/bin/cygcrypto-0.9.7.dll.a.new': No such file or directory cp: cannot stat `libcrypto.dll.a.a': No such file or directory chmod: cannot access `/tmp/bob/lib/libcrypto.dll.a.a.new': No such file or directory mv: cannot stat `/tmp/bob/lib/libcrypto.dll.a.a.new': No such file or directory installing libssl.dll.a cp: cannot stat `cygssl-0.9.7.dll.a': No such file or directory chmod: cannot access `/tmp/bob/bin/cygssl-0.9.7.dll.a.new': No such file or directory mv: cannot stat `/tmp/bob/bin/cygssl-0.9.7.dll.a.new': No such file or directory cp: cannot stat `libssl.dll.a.a': No such file or directory chmod: cannot access `/tmp/bob/lib/libssl.dll.a.a.new': No such file or directory mv: cannot stat `/tmp/bob/lib/libssl.dll.a.a.new': No such file or directory Anyone have any ideas? Any help would be apprecicated. TIA, Chris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question reagrding OpenSSL recent security advisory
Marek Marcola wrote: Hello, I have read the advisory an I am a bit puzzled regarding the there are CAs using exponent 3 in wide use comment, I have tried to check and could not found any CA using this exponent, all the CA’s I have seen are using 0x10001 (CA’s I have generate by OpenSSL using default values, world wide trusted CA’s such as VeriSign and Thawte etc..) are only old CA’s using exponent 3 ? Could anyone elaborate some on this? Look at: http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html That's a rather worthless answer Marek, the question isn't what is the flaw (mishandled exponent 3-signed certificates), but the prevalence. My cursory examination shows most keygen tools have been using F4 style exponents most of this century. Two cases came to mind... Private CA's generated with very old tools (such tools fester a long time) Old signing keys reused for fresh signing request keys (anathema of best practices) but most importantly, public signing keys. Hagai asks how prevalent such exponent 3 public or commercial signing keys still are? Someone stated they are in wide use. This is not 'private' information, and Hagai just asked if someone has done the actual research of affected public/commercial signing authorities? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question reagrding OpenSSL recent security advisory
Hagai, From my research I found that there are some known CA that use exponent of 3 (and some hardware implementation that use that as default). About your ca, if you know that all your components (browsers and/orapplications)that will be involved will have good PKCS#1 implementation, then you should be ok with exponent of 3, or even exponent of 1, in fact it will make your public key operations (encrypt, verify) faster. And if your components don't have PKCS#1 then you have much more to worry about even with bigger exponents. For example the standard OpenSSL RSA signature is RSA+PKCS#1, and i think must other standard implementations as well. However I did see some government documents claiming that even 65537 is not enough, and they recommend even bigger, but I think a lot of that is politics.I know that a lot of people here will disagree but, just do the research and if you know the components involved have good PKCS#1 you should be fine with small public exponents. Anyone that has a good reason to say this is wrong with details, I would love to hear that. Joe Gluck On 9/6/06, Dr. Stephen Henson [EMAIL PROTECTED] wrote: On Wed, Sep 06, 2006, Hagai Yaffe wrote: I have read the advisory an I am a bit puzzled regarding the there are CAs using exponent 3 in wide use comment, I have tried to check and could not found any CA using this exponent, all the CA's I have seen are using 0x10001 (CA's I have generate by OpenSSL using default values, world wide trusted CA's such as VeriSign and Thawte etc..), I understand that specifying CA's using exponent 3 will give specific targets to malicious people and that is defiantly not a good idea, how ever I would like to try and better understand the range of the problem,are only old CA's using exponent 3 ? Could anyone elaborate some on this?I don't want to name names here but a brief study I did revealed 8 public CA root certificates which used exponent 3.Steve.--Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepageOpenSSL project core developer and freelance consultant.Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk__OpenSSL Project http://www.openssl.orgUser Support Mailing Listopenssl-users@openssl.orgAutomated List Manager [EMAIL PROTECTED]
Re: Is there any API available to convert the DER formatted file to Base64 formatted file?
[EMAIL PROTECTED] wrote: Hi Team, Is there any API available in OPENSSL to convert the DER formatted file to Base64 formatted file? Please let me know your thoughts. Thank you. have a look at what openssl base64 ... does (or openssl enc -base64 ...). Cheers, Nils __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
