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]
