RE: Cryptology Questions
It is not the connection I was referring to but the environment that was generating the certs. Was the original user attempting to store his client's generated key pairs on his server? Then that server better be secured. Perhaps I wasn't clear on that point. However, I personally would never use key pairs generated by another to be used for identification purposes. Finally, sniffing/replaying a csr is pointless. You still don't have access to the private key to decrypt messages intended for me if that key was generated by me and remains secured by me. Nor would any CA worth it's salt sign a csr without the proper verification (and payment!) method. As an example, Verisign issues unique identifiers for each csr to an authorized requestor prior to granting the signing request. Once used, a replay is easily detected. -Original Message- From: POLIVKA-ROHRER, KEITH W (AIT) [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 5:53 PM To: '[EMAIL PROTECTED]' Subject: RE: Cryptology Questions Regarding key distribution, no one but the owner should have access to the private key. What reason would the server have for sending a client their public AND private key? To ensure confidentiality and integrity, the key pair should (must?) be generated by the client. It is the job of the CA to sign the certificate (which contains among other things the owner's public key). The private key itself is not contained within the cert. You should read up on certificate requests to clarify some issues. For whatever reason, if you are attempting to generate and supply both keys to you clients, you have to have a very secure environment. More problematic is that, because you have both keys, I am not guaranteed that someone at your company couldn't impersonate me if I were a client... Riddle me this, then: If the connection isn't secure enough to send the (encrypted) private key across, why is it secure enough for the credentials the server should require before signing a CSR? Alternately stated, it's much easier to sniff and replay the certificate request than to sniff the private key and decrypt it. Keith __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] * DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Cryptology Questions
-Original Message- From: Michael Wojcik [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 10:46 PM To: [EMAIL PROTECTED] Subject: RE: Cryptology Questions From: Neff Robert A [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 2:47 PM Indeed, collisions of messages *must* exist. However, by it's very nature, the other message(s) causing the collisions would, with almost 100% certainty, not be valid within the context it was used in. This is a dubious claim. Take a look at Gideon Yuval's protocol for using a birthday attack against a cryptographic hash, as described in AC2 (18.1, p 430): Alice creates two versions of a contract, one fair, the other favorable to her. She uses a cosmetic change - eg. an extra space is either present or not before the newline - on each of N/2 lines in each contract (where N is the size in bits of the hash). By toggling her change - adding or removing the unnecessary space character - on the N/2 lines independently, she obviously can create N/2 variations of each of her two documents. Thanks to the birthday paradox, the odds favor her finding a colliding pair. Then all she has to do is take the fair contract from the pair and convince Bob to sign just the hash (and not, say, make a cosmetic change to the contract, and then hash and sign that), and she can substitute the unfair contract at a later date and demonstrate that it hashes to the value the Bob signed. It's even worst than that: Alice can agree with Bob to the original contract, and have Bob sign it. THEN she have: - The contract itself (which can be used to generate the MD5 digest) - Bob's signed MD5 digest Then applying the birthday attack she can fiddle with the better-for-her contract till it generates the same MD5 digest. The mere fact the MD5 digest is the same makes that Bob's signature match this contract. The fact this can be done afterwards has several implications: 1) As time goes, machines are faster and faster, so the attack is simpler and simpler. Just this should promotes avoiding short digests for long-lived contracts. 2) Bob can decide, as an afterthought, that it may be beneficial for him to repudiate a contract that he've signed, as he can play exactly the same game :-) The only solution to this, that will increase the difficulty of tampering with a contract, is requesting both parts to sign exactly the same contract, but with a mention of which is signing. For example you can have as contract: This contract is between Bob and Alice and say that SO AND SO. Then Bob will sign: This contract is between Bob and Alice and say that SO AND SO. Signed by BOB And Alice will sign: This contract is between Bob and Alice and say that SO AND SO. Signed by ALICE The final contract being: This contract is between Bob and Alice and say that SO AND SO. Bob's signature Alice signature Note that Signed by BOB and Signed by ALICE could be replaced by their certificates, expurged from the public key to avoid any risk of key interference that coudl occur when signing with the private key something that is dependant on the public key. Then the birthday attack will need to find a tampered contract that generates the same MD5 (or SHA1 or SHA-4096 if that ever exist) than the original one for both to-be-signed messages. I'm not an expert but it looks like it would be VERY difficult to find a double collision, perhaps completely defeating the birthday paradox. And anyway such a double signing is requested for a lot of contracts, as a lot of these are mutually binding; if the contract will only bind me, I'd probably arrange to get two certificates from two different CAs, with as much different optional info on each one, and sign the contract twice. Note that you must expect this kind of after-signing compromission to be possible for as long as the CONTRACT is valid, as certificate expiration/revokation is of no help here: once you've signed, you're bound to what you've signed. Or else you have to expect having to sign again regularly ;-( In short, there's a perfectly good algorithm for finding valid colliding documents, assuming you can and want to do the work required for the birthday attack (2 to the power of N/2 on average), and assuming you can make N/2 independent cosmetic changes to each of the documents. Of course, in actual applications those assumptions are often not met; but simply assuming that colliding pairs of valid documents are much harder to find than other collisions is a mistake. Especially as this is simpler and simpler as computer are faster and faster; and anyway every year there's people winning at the lottery... Regards, Bernard Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1
Re: Cryptology Questions
Bernard Dautrevaux [EMAIL PROTECTED] writes: It's even worst than that: Alice can agree with Bob to the original contract, and have Bob sign it. THEN she have: - The contract itself (which can be used to generate the MD5 digest) - Bob's signed MD5 digest Then applying the birthday attack she can fiddle with the better-for-her contract till it generates the same MD5 digest. The mere fact the MD5 digest is the same makes that Bob's signature match this contract. You misunderstand the birthday attack, which involves creating two messages which have the same (previously unknown) digest. The birthday attack requires you to create the message pair upfront, before the signature occurs. The attack you describe: creating a document with a SPECIFIC digest, is 2^n hard (where n is the length of the hash). (Assuming, of course, that no attack better than brute force is known for the digest in question). -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Cryptology Questions
-Original Message- From: Eric Rescorla [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 5:29 PM To: [EMAIL PROTECTED] Subject: Re: Cryptology Questions Bernard Dautrevaux [EMAIL PROTECTED] writes: It's even worst than that: Alice can agree with Bob to the original contract, and have Bob sign it. THEN she have: - The contract itself (which can be used to generate the MD5 digest) - Bob's signed MD5 digest Then applying the birthday attack she can fiddle with the better-for-her contract till it generates the same MD5 digest. The mere fact the MD5 digest is the same makes that Bob's signature match this contract. You misunderstand the birthday attack, which involves creating two messages which have the same (previously unknown) digest. The birthday attack requires you to create the message pair upfront, before the signature occurs. The attack you describe: creating a document with a SPECIFIC digest, is 2^n hard (where n is the length of the hash). (Assuming, of course, that no attack better than brute force is known for the digest in question). Oh, yes; Now I understand why this attack is O(N) when I expected such an attack to be O(2^N) as is effectively an attack as I (mis)understood it. Thanks for the clarification, Bernard Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cryptology Questions
Eric Rescorla wrote: The attack you describe: creating a document with a SPECIFIC digest, is 2^n hard ... Eric is of course correct. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Cryptology Questions
Title: Cryptology Questions Hi all, I was wondering if someone could help me out. I have to speak with some cryptology experts later today and was wondering if some answers could be answered. 1. What is the normal/(most secure) way to store private keys and protect them? Right now I store them in .pem format in a file and encrypt them with DES-CBC. 2. What does it mean if I need someone asks me if we support 'importing X.509 certificate from an external CA'. I thought that you just sign certificates with the CA not import them? Or am I missing something. 3. What is the normal/(most secure) way to validate the presented partners certificates when a SSL connection is established. Now my understanding was the defacto way was to include the ip/hostname in the CN? Is this correct and does it work both ways meaning. Can the server check to see if it's certificates have been move, i.e. if I copy public/private pairs from server a to server b, should server b check the ip/hostname to see if they really belong. And the client should check the certificate obtained from Server A, to see if it's really Server A correct? Ok that's enough with the homework questions. Heh, it's not really homework but im sure that the answers are so easy that it seems like it. :) I bought Eric Rescorla's book 'SSL and TLS' and ive been trying to read that but I don't see where he goes into more detail about 'storing keys' and ensuring safety. Of course I could of just blown right by that chapter, I tend to read books backwards. Now for my own interest. I see many names being thrown around. I'll tell you what I 'think' I know and please correct me if im wrong. RSA is a public key cryptology. I take this to mean that the public and private keys ( i.e. certificate/key ) is encrypted over the wire with RSA? Actual application ( for my example we will say application ) data is encoded into a message and then encrypted with a Message Digest? Which can be either MD5 or SHA-1 for RSA but only SHA-1 for DSS. Now this is where I get confused. RSA is also used like DH, in that it's used to negotiate a session key? Is that correct? So basically RSA does two things while DSS relies on DH to be complete? Let me see if I can translate this cipher: EDH-DSS-DES-CBC3-SHA. I take this to mean that the session key is negotiated with Emperhal DH meaning it's randomly generated on one side and not known by both parties. It uses DSS for public key encryption, DES for the actual data stream. I don't know what CBC3 means. But the Message Digest is SHA. Now what's the difference between encypting with a message digest with SHA but encrypting the data with DES? I thought the message was the data. Also reading in Eric's book he says 1024-bit assymetric keys are about as strong as 80-bit symmertic keys. So why is assymetric used? I assume its because of performance. It would probably take to long if everything was encrypted with 3DES correct? I do apologize for all these questions but I really want to learn SSL and in general Security and Cryptology inside and out but all the different encyptions are throwing me for a loop. I always just thought of cryptology in the terms of using RSA, DES or 3DES but I see there is a lot more to it. THANKS! - Andrew - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485
RE: Cryptology Questions
Title: Cryptology Questions hmmm...a tall order for us busy folks...but I'll help you out some. 1. Provided you are using a "strong" password to encrypt your key when using DES-CBC you are pretty secure. Remember that if I can get access to, orcopy, your .pem file from off your machine I can run a dictionary attack against it, searching for your encryption password. If I find that, I can impersonate you. 2. Importing a certificate to me sounds like you are being asked if you are adding the cert to either your browser's trusted store or your server's cert chain. Some additional info would help clear that up a bit. 3. First, It is very important that, when validating a cert, you first check that the issuer of that cert is trusted by you. OpenSSL does this rather easily for you, once you've informed it of the CA certs you trust. You must do this because I can easily create a certificate containing www.verisign.comas the issuer but would have to somehow convince you to store my fake CA cert within your store. The entire issue of trust within the PKI framework begins with the CA certs you trust. If you don't understand this completely, please read up more on this topic at either Verisign's or RSA's web site. They have decent tutorials on PKI. Second, you then check that the cert has not expired. The notBefore/notAfter time periods contained within the cert indicate what period of time the cert can be valid. Of course, this is how the major CA's make their money, by limiting this period to usually one year from issuance. Third, you check the CN of the cert to ensure that it is indeed the site you are intent on conversing with. You can do additional checks if you wish to enforce certificate extensions. However I've not had much experience using those so I'll defer to others... RSA is an algorithm create to use apublic/private key pair where, if using one key for encryption, you use the other for decryption. If I know your public key, I can encrypt data and send it to you, confident that ONLY you can decrypt it. However, it is a slow algorithm compared to the symmetrical ones. That is why it is using only during the SSL handshakefor certificate verification and fortransferring the SSL session keys. It is not used for bulk data encryption likeDES/AES/RC4/etc... Regarding your thoughts on MD5, it is a Message Digest (the MD) of the content being sent. It is not encrypting the data, per say, but rather creating a strong "checksum", if you will,of the contents. You can then encrypt the MD with your private key and send it along with your message. Upon receiving your message I woulddecrypt the MD using your public key, re-compute the MD of the message sent, and compare it to the decrypted MD. If they are identical, I know that a) the message has not been tampered with and b) it could only have been sent by you since only you would have the corresponding private key to encrypt the MD in the first place. I know I've glossed over the many details here but hope this is the clarification you are looking for. If not, ask again. HTH, Rob -Original Message-From: Andrew Finnell [mailto:[EMAIL PROTECTED]]Sent: Thursday, December 06, 2001 9:17 AMTo: 'Openssl ([EMAIL PROTECTED])'Subject: Cryptology Questions Hi all, I was wondering if someone could help me out. I have to speak with some cryptology experts later today and was wondering if some answers could be answered. 1. What is the normal/(most secure) way to store private keys and protect them? Right now I store them in .pem format in a file and encrypt them with DES-CBC. 2. What does it mean if I need someone asks me if we support 'importing X.509 certificate from an external CA'. I thought that you just sign certificates with the CA not import them? Or am I missing something. 3. What is the normal/(most secure) way to validate the presented partners certificates when a SSL connection is established. Now my understanding was the defacto way was to include the ip/hostname in the CN? Is this correct and does it work both ways meaning. Can the server check to see if it's certificates have been move, i.e. if I copy public/private pairs from server a to server b, should server b check the ip/hostname to see if they really belong. And the client should check the certificate obtained from Server A, to see if it's really Server A correct? Ok that's enough with the homework questions. Heh, it's not really homework but im sure that the answers are so easy that it seems like it. :) I bought Eric Rescorla's book 'SSL and TLS' and ive been trying to read that but I don't see where he goes into more detail about 'storing keys' and ensuring safety. Of course I could of just blown right by that chapter, I tend to read books backwards. Now for my own interest. I see many names being thrown around. I'll te
RE: Cryptology Questions
Title: RE: Cryptology Questions Neff, Thanks for the quick response. You actually helped me understand some aspects that I didnt truely understand before. For example the message digest. I did not know it was a checksum to validate that the data wasn't altered. --- More questions( better questions I guess? ) Regarding brute force attacks on the private key, what other mechanism is there to protect these keys and distribute them for that matter. For instance is it valid to have a server send a client it's public/private key pairs to use. Then reconnect the server with those keys. The security would come into play because the client needs to know the password to decrypt the private key that it was sent. Is this a good way to distribute client public/private keys? Sneaker footing/emailing the keys or methods that aren't automated or easy to use isn't really available to me. As for importing the X.509 certificate, I am focusing on adding it to the certificate chain. How are most certificates stored? Is it just as simple as opening up the certificate.pem(client cert) file and performing some openssl operations to add a cacert.pem(server cert) to the chain? This seems to easy and to prone to attacks. Anyone could just open the file and add there ca. BTW, thanks for the help anyone can give me. I know everyone is busy and I dont demand that people answer :) I just find that mailing lists like these are full of people that have the answers. - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485 -Original Message- From: Neff Robert A [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 10:20 AM To: '[EMAIL PROTECTED]' Subject: RE: Cryptology Questions hmmm...a tall order for us busy folks...but I'll help you out some. 1. Provided you are using a strong password to encrypt your key when using DES-CBC you are pretty secure. Remember that if I can get access to, or copy, your .pem file from off your machine I can run a dictionary attack against it, searching for your encryption password. If I find that, I can impersonate you. 2. Importing a certificate to me sounds like you are being asked if you are adding the cert to either your browser's trusted store or your server's cert chain. Some additional info would help clear that up a bit. 3. First, It is very important that, when validating a cert, you first check that the issuer of that cert is trusted by you. OpenSSL does this rather easily for you, once you've informed it of the CA certs you trust. You must do this because I can easily create a certificate containing www.verisign.com as the issuer but would have to somehow convince you to store my fake CA cert within your store. The entire issue of trust within the PKI framework begins with the CA certs you trust. If you don't understand this completely, please read up more on this topic at either Verisign's or RSA's web site. They have decent tutorials on PKI. Second, you then check that the cert has not expired. The notBefore/notAfter time periods contained within the cert indicate what period of time the cert can be valid. Of course, this is how the major CA's make their money, by limiting this period to usually one year from issuance. Third, you check the CN of the cert to ensure that it is indeed the site you are intent on conversing with. You can do additional checks if you wish to enforce certificate extensions. However I've not had much experience using those so I'll defer to others... RSA is an algorithm create to use a public/private key pair where, if using one key for encryption, you use the other for decryption. If I know your public key, I can encrypt data and send it to you, confident that ONLY you can decrypt it. However, it is a slow algorithm compared to the symmetrical ones. That is why it is using only during the SSL handshake for certificate verification and for transferring the SSL session keys. It is not used for bulk data encryption like DES/AES/RC4/etc... Regarding your thoughts on MD5, it is a Message Digest (the MD) of the content being sent. It is not encrypting the data, per say, but rather creating a strong checksum, if you will, of the contents. You can then encrypt the MD with your private key and send it along with your message. Upon receiving your message I would decrypt the MD using your public key, re-compute the MD of the message sent, and compare it to the decrypted MD. If they are identical, I know that a) the message has not been tampered with and b) it could only have been sent by you since only you would have the corresponding private key to encrypt the MD in the first place. I know I've glossed over the many details here but hope this is the clarification you are looking for. If not, ask again. HTH, Rob -Original Message- From: Andrew Finnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 9:17 AM To: 'Openssl ([EMAIL PROTECTED])' Subject
RE: Cryptology Questions
On Thu, 6 Dec 2001, Andrew Finnell wrote: digest. I did not know it was a checksum to validate that the data wasn't altered. It's more robust than the usual checksums (CRC). You can easily fool a CRC32, but fooling a cryptographic digest is another matter... In fact, for MD5 and SHA1, nobody managed to show a collision. Regarding brute force attacks on the private key, what other mechanism is there to protect these keys and distribute them for that matter. For instance is it valid to have a server send a client it's public/private key pairs to use. Then reconnect the server with those keys. The security would come into play because the client needs to know the password to decrypt the private key that it was sent. Is this a good way to distribute client public/private keys? Sneaker footing/emailing the keys or methods that aren't automated or easy to use isn't really available to me. You generally don't distribute the private keys. The private/public key is generated by the client, and the public key is then sent to a CA, which signs it along with identity informations (so that the identity is bound to the public key). The private key is never distributed... As for importing the X.509 certificate, I am focusing on adding it to the certificate chain. How are most certificates stored? Is it just as simple as opening up the certificate.pem(client cert) file and performing some openssl operations to add a cacert.pem(server cert) to the chain? This seems to easy and to prone to attacks. Anyone could just open the file and add there ca. It depends of what you understood about the certificate chain. A certificate chain is not built by the running program (for example like a linked list of objects in memory). In fact, a certificate chain exists even if you don't have the certificates. Certificates A and B belong to the same chain if they have a common parent, and this cannot be fooled. You won't be able to make me believe that C belongs to the A's chain if C and A have no parent in common. The only entity that should be incontionally trusted is the root. All the other certificates are implicitely trusted because the root is trusted. If anobody could come on your PC and make your software trust a new root, too bad... The security of the whole chain is equal to the security of it's weakest link. Here, it's the protection you put to avoid someone getting access to your PC. In some cases, the weakest link is the user itself, who doesn't understand what it does... -- Erwann ABALEA [EMAIL PROTECTED] RSA PGP Key ID: 0x2D0EABD5 - (A)bort, (R)etry, (S)mack the @#$*! thing! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cryptology Questions
Erwann ABALEA [EMAIL PROTECTED] writes: On Thu, 6 Dec 2001, Andrew Finnell wrote: digest. I did not know it was a checksum to validate that the data wasn't altered. It's more robust than the usual checksums (CRC). You can easily fool a CRC32, but fooling a cryptographic digest is another matter... In fact, for MD5 and SHA1, nobody managed to show a collision. That's MOSTLY true. Hans Dobbertin showed a single compression in the MD5 compression function but noone in the open community knows how he got it. Of course, it's obvious that there must be collisions and for MD5 at least it's technically possible to find them by brute force, since the birthday attack is 2^64 hard. This doesn't mean that the use of MD5 in SSL is insecure. The only property that SSL really requires of MD5 is irreversibility which is 2^128 hard. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cryptology Questions
Andrew Finnell [EMAIL PROTECTED] writes: I was wondering if someone could help me out. I have to speak with some cryptology experts later today and was wondering if some answers could be answered. 1. What is the normal/(most secure) way to store private keys and protect them? Right now I store them in .pem format in a file and encrypt them with DES-CBC. Well, there's normal and there's most secure. Normal is to store them in a PEM file encrypted under a password. Essentially you take the password and run it through a hash function to get a DES (or better yet, 3DES) key. This has a number of problems, the two foremost being: (1) Someone who gets your .pem file can try to password search to get the private key. This won't work if you've used a strong password but those can be hard to generate and remember. (2) Someone who breaks into your computer while it's running the server can the private key out of memory. The most secure way is to store the keys in some hardware device which is designed to let you perform public key ops with the key but never to give up the key -- and to zero itself if you tamper with it. They can also be designed to be unusable without a passphrase. This material is covered in section 5.11 of SSL and TLS, pp. 146-154. 2. What does it mean if I need someone asks me if we support 'importing X.509 certificate from an external CA'. I thought that you just sign certificates with the CA not import them? Or am I missing something. Ok. Roughly speaking there are two ways to get a certificate: (1) issue it yourself and (2) use CA. Issue it yourself means that you create a self-signed certificate when you generate your key. Using a CA means you generate a certificate signing request, give it to your CA and the CA gives back a certificate. You then have to load that certificate into your software. A degenerate case of a CA is a local CA in which you run your own. You might use a private protocol between you and your CA and not be able to support CAs run by third parties such as VeriSign. (For instance, your system might have custom extensions that need to be in the certs). What this question _might_ mean is can you use certificates issued by a third party CA. 3. What is the normal/(most secure) way to validate the presented partners certificates when a SSL connection is established. Now my understanding was the defacto way was to include the ip/hostname in the CN? Yes. See SSL and TLS S 9.14 pp 307-314. Is this correct and does it work both ways meaning. Can the server check to see if it's certificates have been move, i.e. if I copy public/private pairs from server a to server b, should server b check the ip/hostname to see if they really belong. And the client should check the certificate obtained from Server A, to see if it's really Server A correct? The client ALWAYS needs to check this stuff. The server might want to check it's own certificate in order to detect misconfigurations but it's not really necessary. Ok that's enough with the homework questions. Heh, it's not really homework but im sure that the answers are so easy that it seems like it. :) I bought Eric Rescorla's book 'SSL and TLS' and ive been trying to read that but I don't see where he goes into more detail about 'storing keys' and ensuring safety. Of course I could of just blown right by that chapter, I tend to read books backwards. Most of this material is covered (though I want to talk more about real world certificate policy in 2ed). The following material is all covered in SSL and TLS, mostly in Chapter 1,3, and 4 but I'll take a stab at summarizing. RSA is a public key cryptology. I take this to mean that the public and private keys ( i.e. certificate/key ) is encrypted over the wire with RSA? Not quite. Say we have some message (M) that we want to send from Alice to Bob. If we use ordinary (symmetric) cryptography then Alice and Bob need to share a key, K, and we do: Ciphertext=Esymmetric(K,M). If we use public key (assymetric) crypto then Bob has a Public Key (Kpub) and a Private Key (Kpriv). Alice can send a message to Bob that only Bob can decrypt (even Alice can't) doing: Ciphertext=Ersa(Kpub,M) Bob can decrypt it doing: M=Drsa(Kpriv,Ciphertext) However, for a number of technical reasons (mainly performance) RSA isn't really suitable for encrypting actual ASCII messages. Instead you encrypt symmetric keys with RSA and then use the symmetric keys to encrypt the message. E.g. Ciphertext=Ersa(Kpub,Ksymmetric) + Esymmetric(Ksymmetric,Message) RSA can also do another trick, which is that if you encrypt with the private key you get something that can only be decrypted with the public key (and could only have been generated with the private key). This can be used to prove that the sender had the private key and is called a digital signature. I.e. Signature=Ersa(Kpriv,Message) To verify you
RE: Cryptology Questions
Title: RE: Cryptology Questions Yes, the digest is used to validate that the data wasn't altered. Remember that anyone can calculate the digest of a message. If the digest wasn't encrypted with your private key, then someone could change the data, recompute the digest, and exchange the original digest with the newly computed one. Encrypting the MD with your private key prevents that from occurring. That, in a nutshell, is digitally signing a document. Regarding key distribution, no one but the owner should have access to the private key. What reason would the server have for sending a client their public AND private key? To ensure confidentiality and integrity, the key pair should (must?) be generated by the client. It is the job of the CA to sign the certificate (which contains among other things the owner's public key). The private key itself is not contained within the cert. You should read up on certificate requests to clarify some issues. For whatever reason, if you are attempting to generate and supply both keys to you clients, you have to have a very secure environment. More problematic is that, because you have both keys, I am not guaranteed that someone at your company couldn't impersonate me if I were a client... Certificates themselves are public. Anyone can, and does, have knowledge of their contents. OpenSSL comes with some of the major CA signing certificates in use. You will find them in the openssl/certs directory. You indicate to OpenSSL which of these certs you trust to sign other certs. You can obtain these certs directly from the vendor if you don't trust the ones in the distribution. It is the public key contained within these CA certs that is used to decrypt the MD of the server certificate received during the SSL connection that was encrypted (signed)with theissuing CA's private key. And yes, a possible attack would be that someone could addtheir own version of a "verisign" root cert to your store, hijack a DNS server to reroute your IP connection to another server, then use that server to act as a proxy to the original server. Fortunately, this is not an easy thing to accomplish since many machines need to be compromised. The attacker would still not have access to your private key though. Sleep tight! hehe Cheers, Rob -Original Message-From: Andrew Finnell [mailto:[EMAIL PROTECTED]]Sent: Thursday, December 06, 2001 10:40 AMTo: '[EMAIL PROTECTED]'Subject: RE: Cryptology Questions Neff, Thanks for the quick response. You actually helped me understand some aspects that I didnt truely understand before. For example the message digest. I did not know it was a checksum to validate that the data wasn't altered. --- More questions( better questions I guess? ) Regarding brute force attacks on the private key, what other mechanism is there to protect these keys and distribute them for that matter. For instance is it valid to have a server send a client it's public/private key pairs to use. Then reconnect the server with those keys. The security would come into play because the client needs to know the password to decrypt the private key that it was sent. Is this a good way to distribute client public/private keys? Sneaker footing/emailing the keys or methods that aren't "automated" or easy to use isn't really available to me. As for importing the X.509 certificate, I am focusing on adding it to the certificate chain. How are most certificates stored? Is it just as simple as opening up the certificate.pem(client cert) file and performing some openssl operations to add a cacert.pem(server cert) to the chain? This seems to easy and to prone to attacks. Anyone could just open the file and add there ca. BTW, thanks for the help anyone can give me. I know everyone is busy and I dont demand that people answer :) I just find that mailing lists like these are full of people that have the answers. - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485 * DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator.
