RE: Accessing encrypted messages after cert expires
Doesn't what you suggest create a headache? Every time I want to decrypt an old message I sent or I received, or a file, I will need to change the mail client configuration and point it to another private key. One would hope your mail client will allow you to keep any number of key pairs for decryption use, with one selected as 'active' to be the default for encryption. Keeping the same key overcomes this problem. Have I got this right? Why is it not feasible to retain the same private key? You can retain the same private and public key but generate a new certificate if you wish. The problem is that this reduces the security by extending the lifespan of the key. This may be entirely reasonable if the lifespan of the certificate is based on other concerns than the lifespan of the key. For example, suppose I create a public/private keypair that I don't think anyone can break for 50 years. If I make the certificate valid for 30 years because of this, it would obviously be a bad idea to keep the same key for a new certificate. On the other hand, if I make the certificate valid for two years because I can only assure that the identity in the certificate will belong to the key owner for that long, there's no harm in re-using the same key in the next certificate if I know the identity is good for another two years. (The key being safe for 48 years rather than 50 is a negligible difference, but don't renew the certificate for the same key forever.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
Hello Mick: Mick wrote: snip Yes it does. Keeping the same private key and generating new public key with it seems to be a sensible thing to do from a practical point of view. Be careful - first of all - you can't generate a new public key - you can generate a new certificate request, but it will use the same public key as used in the now expired certificate - that's just how asymmetric cryptosystems work. And, the longer that a particular keypair is used, the higher the likelihood that that key will be broken or compromised. That's one of the reasons that most CA's have fairly short validity periods for user certificates and keys. And just to short circuit the discussion of But I'm using 2048 bit keys, so I'm OK, you are probably using SHA-1 in the signature algorithm, which isn't necessarily OK. And please talk to Microsoft about backporting SHA256 into their operating systems before Vista so that we can fix that particular problem... everything else supports SHA-256, except most widely deployed versions of Windows. :) Speaking of validity periods, you should check with your CA to find out what their key lifetime rules are - most are the same as for the certificate, although I've seen variations. The key lifetimes should be listed in the Certificate Policy of the CA that you are using. Have fun. --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
On Sat, Mar 15, 2008 at 11:36 PM, David Schwartz [EMAIL PROTECTED] wrote: For example, suppose I create a public/private keypair that I don't think anyone can break for 50 years. If I make the certificate valid for 30 years because of this, it would obviously be a bad idea to keep the same key for a new certificate. On the other hand, if I make the certificate valid for two years because I can only assure that the identity in the certificate will belong to the key owner for that long, there's no harm in re-using the same key in the next certificate if I know the identity is good for another two years. (The key being safe for 48 years rather than 50 is a negligible difference, but don't renew the certificate for the same key forever.) Arguably, you shouldn't do it even once, because it's extremely easy to fall into the pattern of one key and one key only in the systems design or implementation. I can't remember who coined the phrase, but it's not good crypto hygeine. Granted, there are some circumstances where such a risk is acceptable [a different threat model than that used by vanilla X.509 or PKIX can render the risk a non-issue], but in general it should be avoided if possible. (and there's not enough resources available to code it isn't really a good reason for calling it impossible.) -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
On Sunday 16 March 2008, David Schwartz wrote: Doesn't what you suggest create a headache? Every time I want to decrypt an old message I sent or I received, or a file, I will need to change the mail client configuration and point it to another private key. One would hope your mail client will allow you to keep any number of key pairs for decryption use, with one selected as 'active' to be the default for encryption. Keeping the same key overcomes this problem. Have I got this right? Why is it not feasible to retain the same private key? You can retain the same private and public key but generate a new certificate if you wish. The problem is that this reduces the security by extending the lifespan of the key. This may be entirely reasonable if the lifespan of the certificate is based on other concerns than the lifespan of the key. For example, suppose I create a public/private keypair that I don't think anyone can break for 50 years. If I make the certificate valid for 30 years because of this, it would obviously be a bad idea to keep the same key for a new certificate. On the other hand, if I make the certificate valid for two years because I can only assure that the identity in the certificate will belong to the key owner for that long, there's no harm in re-using the same key in the next certificate if I know the identity is good for another two years. (The key being safe for 48 years rather than 50 is a negligible difference, but don't renew the certificate for the same key forever.) Thanks guys! I have understood the principle of this now. Let's hope that I will not mess things up when I migrate from this PC to another and lock myself out of accessing my (older) docs and emails. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
How to debug Openssl DLL
Hello, I ceated the debug version of ssleay32.dll and libeay32.dll. I have an application compiled with VS2005 (MTD). How can I link the source code of Openssl to my application with VS2005? Thanks! _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Debug assertion failed. Expression: (_osfile(fh)FOPEN) with VS2005
I use VS2005 to create a private RSA key. But I always get the error from the file setmode.c line 58: Expression: (_osfile(fh)FOPEN) --Debug assertion failed RSA *r =NULL; int bits=512; unsigned long e=RSA_3; FILE *privateKeyFile; r=RSA_generate_key(bits,e,NULL,NULL); fopen_s(privateKeyFile,Privatekey, w); //privateKeyFile = fopen(Privatekey, w); PEM_write_RSAPrivateKey(privateKeyFile, r,NULL,NULL, 0,NULL, NULL); The error comes from the function PEM_write_RSAPrivateKey(). Please help me! _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
RE: Accessing encrypted messages after cert expires
Arguably, you shouldn't do it even once, because it's extremely easy to fall into the pattern of one key and one key only in the systems design or implementation. I can't remember who coined the phrase, but it's not good crypto hygeine. I have argued many times that not including the creation date in every private key data format was a *huge* mistake. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
Patrick Patterson wrote: Actually, what you care about are the keys associated with the certificate. For encryption, you've got content that is encrypted with the public key, and decryptable only with the private key. Since the certificate is your public key signed by some Certificate Authority or other (or, itself), then after the certificate expires, most software will not let you or others encrypt things with that public key. However, since you are still in possession of the private key, you should still be able to decrypt everything just fine. A cert is more than a public key signed by a CA -- it's a binding of that key to an identity (in this case an email addr?). Never mind the red herring of calling it an SSL cert, it's apparently used here for the purposes of SMIME encryption, which requires the use of two public-private key pairs in the case in which an email is encrypted and signed (and sent to another party). For enveloped data, the content-encryption key is encrypted for each recipient (using the recipient's public key); for signed messages, the private key of the sender is used appropriately to generate the signature. This requires that both the sender's public key and the recipient's private key be known and usable into the foreseeable future, independent of cert expiration. Keys don't expire -- certificates do. Expiration of a cert should only render invalid any messages signed (in the case of expiration of the sender's cert) or encrypted (in the case of expiration of the recipient's cert) after the expiration date. AFAIK many (most) MUAs which support SMIME will keep certs in their database forever, until purged. And why would you need to protect a private key when its associated public key is longer used for encryption, and when the key itself is no longer used for signing? - Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
David Schwartz wrote: Arguably, you shouldn't do it even once, because it's extremely easy to fall into the pattern of one key and one key only in the systems design or implementation. I can't remember who coined the phrase, but it's not good crypto hygeine. I have argued many times that not including the creation date in every private key data format was a *huge* mistake. And you have argued wrongly. Such matters of key usage policy are in the domain of the CA and/or RA -- They have nothing to do with cryptography per se. - Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: MAC
Main, James J Civ USAF AMC DET 3 AMCAOS/DOHJ wrote: Is there a driver available for MAC using ActivClient CAC 6.1? If so where is it available. Hey, Jim - does ActivClient present itself as a cryptosystem service, a la PKCS#11 or Microsoft's Smart Card interface? Regards. - Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
David Schwartz wrote: Arguably, you shouldn't do it even once, because it's extremely easy to fall into the pattern of one key and one key only in the systems design or implementation. I can't remember who coined the phrase, but it's not good crypto hygeine. I have argued many times that not including the creation date in every private key data format was a *huge* mistake. Furthermore -- How do you know what time it is? How do I know you know what time it is? Do I trust you to put the correct time, or even a monotically increasing sequence, into such a structure? See? It's utterly useless, even as a thought experiment. As soon as you need reliance on the truth value of an assertion (validity of a timestamp), you're already in TRUST territory. Might as well let the CA decide not to reissue/resign a cert with an existing pubkey. - Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Accessing encrypted messages after cert expires
I have argued many times that not including the creation date in every private key data format was a *huge* mistake. Furthermore -- How do you know what time it is? How do I know you know what time it is? Do I trust you to put the correct time, or even a monotically increasing sequence, into such a structure? See? It's utterly useless, even as a thought experiment. As soon as you need reliance on the truth value of an assertion (validity of a timestamp), you're already in TRUST territory. Might as well let the CA decide not to reissue/resign a cert with an existing pubkey. If you can't trust the system that generates and stores your private key, you're screwed anyway. So I don't see that this argument has any validity. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
David Schwartz wrote: If you can't trust the system that generates and stores your private key, you're screwed anyway. So I don't see that this argument has any validity. A timestamp is not an attribute of a private key. It's utterly irrelevant. If your purpose is to require that new certificates bound to an entity upon expiration of old certs have a different key, do that. Multiplying your misunderstanding by zero does not improve matters, even for large values of zero. - M __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Accessing encrypted messages after cert expires
On Sun, Mar 16, 2008 at 10:44 PM, David Schwartz [EMAIL PROTECTED] wrote: If you can't trust the system that generates and stores your private key, you're screwed anyway. So I don't see that this argument has any validity. The issue is 'who is trusting what?' David's apparent statement is the person trusting the time is the person generating the key. Michael's apparent idea is if you're generating it and including it in the key format, then you're making an assertion which must trustable by people other than the person generating the key. -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
