Re: RSA keys auth.
Why not use simple challenge/response password authentication? -- David Schwartz <[EMAIL PROTECTED]> On Sun, 6 Jan 2002 00:36:22 -0800 (PST), Vadim Zaliva wrote: >Hi! > >I am trying to use OpenSSL to build secure authenticated channel between >client and server. I want server to allow connections only from certain >clients, and I want client to be sure it is connected to the right server. > >I see how it could be done using certificates. However for my application >generating certificates would be to complex for end user. > >The simplest way I see it would be to use RSA public/private keys: the way >SSH does. So client and server each would have private/public key pairs >generated. When, I would manually add server public key to client side and >client public key to server side (server will possibly have more that one >client key). > >If there is anything wrong with the way I am planning to do it? It seems to >me that this should be pretty common usage. If somebody done this before I >would appreciate any advice. I am new to openssl and still learning basics. > >Sincerely, Vadim > >-- >"La perfection est atteinte non quand il ne reste rien a ajouter, mais quand >il ne reste rien a enlever." (Antoine de Saint-Exupery) > > > > >__ >OpenSSL Project http://www.openssl.org User >Support Mailing List[EMAIL PROTECTED] Automated >List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
On Sun, Jan 06, 2002 at 12:36:22AM -0800, Vadim Zaliva wrote: > Hi! > > I am trying to use OpenSSL to build secure authenticated channel between > client and server. I want server to allow connections only from certain > clients, and I want client to be sure it is connected to the right server. > > I see how it could be done using certificates. However for my application > generating certificates would be to complex for end user. > > The simplest way I see it would be to use RSA public/private keys: the way > SSH does. So client and server each would have private/public key pairs > generated. When, I would manually add server public key to client side and > client public key to server side (server will possibly have more that one > client key). > > If there is anything wrong with the way I am planning to do it? It seems > to me that this should be pretty common usage. If somebody done this > before I would appreciate any advice. I am new to openssl and still > learning basics. This seems fine. The only problem (and its a problem in ssh aswell) is the weak key binding. Its the warning you get in ssh when you change a host key. Warning Host key changed. Man in the Middle attack possible. blah blah blah. Most people just punch in yes and connect. How do you know its not a man in the middle attack? If you use certificates you can change the host key, and the client knows its a legitimate change because the key has been signed by a known CA. Thus you never have such a problem. If the certificate doesn't check out, then you know for *sure* that something is up. Of course if you use a strict check on your rsa host key, say that if the rsa host key doesn't match for that host you refuse a connection, then thats not a prob. The other weak key binding problem is when you first connect (unknown host key, blah blah, should I add it to known hosts?). What if someone has set up a man-in-the-middle before your first connect. There is no way of knowing. A certificate removes these problems because if both the client and server know in advance about the CA (even if the CA is you, not a real CA) then on the first connect, your client can determine for sure if the host key is legit, or forged. So the answer really depends on what you want to do, and how secure is secure? Kind Regards Crispin __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
Vadim Zaliva <[EMAIL PROTECTED]> writes: > I am trying to use OpenSSL to build secure authenticated channel between > client and server. I want server to allow connections only from certain > clients, and I want client to be sure it is connected to the right server. > > I see how it could be done using certificates. However for my application > generating certificates would be to complex for end user. > > The simplest way I see it would be to use RSA public/private keys: the way > SSH does. So client and server each would have private/public key pairs > generated. When, I would manually add server public key to client side and > client public key to server side (server will possibly have more that one > client key). > > If there is anything wrong with the way I am planning to do it? It seems > to me that this should be pretty common usage. If somebody done this > before I would appreciate any advice. I am new to openssl and still > learning basics. This can't be done with SSL exactly the way you want to do it. The only way that SSL knows how to carry public keys is via certificates. Accordingly, what you need to do is use self-signed certificates. At this point you have two authentication options: (1) Hardwire in the certificate values (or public key values) on either side. It's conventional to use a digest of the certificate/key instead of the actual value. (2) Do what SSH does for the server. When the client first connects hope that there's no man-in-the-middle and assume that the certificate is genuine. Write it down and from that point on check the key the peer presents against the cached key. As Crispin points out, this has a few security problems, but it's better than nothing. Essentially, SSH trusts that the first time you connect you actually get to the right host. Given the frequency of actual attacks on the net, this isn't THAT bad an assumption. The traditional thing to do with SSH is for the client to get the server's public key the first time he connects. The client then authenticates to the server with a password. Once the client has authenticated he puts his own public key on the server. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] Author of "SSL and TLS: Designing and Building Secure Systems" http://www.rtfm.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
Besides the fact that using raw public/private key pairs is in my mind a disaster waiting to happen to all SSH users: . they have no notion of identity associated with them . they have no notion of trust associated with them . they have no notion of usage associated with them . they have no ability to be expired . they have no ability to be revoked if compromised private keys are stored in most cases on the disks of insecure operating systems protected only by a passphrase chosen by a end user that knows nothing about security. An insecure OS is one that is either unmanageable or one that is not properly maintained from a security perspective. No OS maintained by the end user is secure. A passphrase consisting of human readable/typable text provides approximately 2 bits of entropy per character. Therefore, to provide an equivalent strength key to protect a 1024 bit private key would require a passphrase at least 64 characters long. Since most passphrases are significantly shorter, not more than an 8 character password, dictionary attacks to extract the private key are highly effective. I am simply waiting for the virus/worm that as part of its operation steals SSH identity and known_hosts files and sends them off to be dictionary attacked. The difference between raw public/private key pairs and X.509 certs is that the cert is a centrally managed object that can be revoked. Something that is revoked cannot be used again by the end user. In other words, the end user cannot simply copy re-use their previous generated key pair. If the user can generate a public/private key pair then they can with appropriate tools provided by you generate a Certificate Signing Request, send the CSR to your host, have it signed and installed. Its more work on your part not on the end users. - Jeff > Hi! > > I am trying to use OpenSSL to build secure authenticated channel between > client and server. I want server to allow connections only from certain > clients, and I want client to be sure it is connected to the right server. > > I see how it could be done using certificates. However for my application > generating certificates would be to complex for end user. > > The simplest way I see it would be to use RSA public/private keys: the way > SSH does. So client and server each would have private/public key pairs > generated. When, I would manually add server public key to client side and > client public key to server side (server will possibly have more that one > client key). > > If there is anything wrong with the way I am planning to do it? It seems > to me that this should be pretty common usage. If somebody done this > before I would appreciate any advice. I am new to openssl and still > learning basics. > > Sincerely, > Vadim > > -- > "La perfection est atteinte non quand il ne reste rien a ajouter, mais > quand il ne reste rien a enlever." (Antoine de Saint-Exupery) > > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
Jeffrey Altman wrote: > A passphrase consisting of human readable/typable text provides > approximately 2 bits of entropy per character. English text contains approx. 3.5 bits of entropy per character. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
Michael Sierchio <[EMAIL PROTECTED]> writes: > Jeffrey Altman wrote: > > > A passphrase consisting of human readable/typable text provides > > approximately 2 bits of entropy per character. > > English text contains approx. 3.5 bits of entropy per character. This seems high, considering that only 6 bits are required to render every alphanumeric message (and only a little over 5 bits is required if you use only one case). Schneier's estimate is even more conservative than Jeffrey's. Ordinary English text contains 1.0-1.5 bits per character. Schneier cites Shannon[0] and Cover[1] Michael, perhaps you're thinking of the REDUNDANCY of English, which is roughly 3.4 bits/character (4.7 bits is required to render all 26 letters, so if you subtract 1.3 from 4.7...) That said, it's not clear how these results apply to passwords. The entropy of short chunks of text is lower. Shannon claims about 2.3 bits/char for 8-letter chunks. OTOH, passwords which are specifically well chosen can have very high entropies. Memorizing strings of 8-16 random characters is quite practical [2] and such strings (even when limited to typed text) can have entropies as high as 6+ bits/character. -Ekr [0] Shannon, C.E., "Predication and Entropy in Printed English" [1] Cover, T.M., King, R.C., "A Convergent Gambling Estimate of the Entropy of English", in IEEE Trans. Info. Theory., July 1978. [2] OTOH, most people aren't willing to do this, so this is a best case scenario for situations where users care about security. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
Eric Rescorla wrote: > That said, it's not clear how these results apply to passwords. > The entropy of short chunks of text is lower. No. The entropy of short chunks of text, without syntax, is higher. Grammatical text is more redundant. Frequency vocabulary is different from dictionary vocabulary, too -- words people use in speech are shorter. Passphrases such as those used in S/Key BE SIR WITH EASY RUBY RUBY GAIL FOND FEE YANG FACE SLOG COT KEN WIRE DARE STAY EYED CHOU MOOD LOW ORR MAGI BILK BEEF OWN KERR ROSY UTAH VEAL LAIN ICON NECK HAST JEFF GRAY BEE HAUL TUNA TERM WELT BOO SOME PUT PEA SEEN GO TWIN FADE GUST TIN SOME FLAG OFF GLIB BOAR CASK SILL SIN ARTS etc. consist of six words chosen from a dictionary of 2048. 2048^6 = 2^66. It gets better, of course, if you use them as one-time passwords. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
Michael Sierchio <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > > That said, it's not clear how these results apply to passwords. > > The entropy of short chunks of text is lower. > > No. The entropy of short chunks of text, without syntax, is > higher. That's what I meant, higher :) That's why my next sentence was: "Shannon claims about 2.3 bits/char for 8-letter chunks." -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: RSA keys auth.
On Sun, 6 Jan 2002, David Schwartz wrote: > Why not use simple challenge/response password authentication? That is one of the options I am considering. I am not sure how to store password on server side and what would be exchange sequence. Vadim -- "La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever." (Antoine de Saint-Exupery) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
On 6 Jan 2002, Eric Rescorla wrote: I would like to thank everybody who responded to my previous messages. > This can't be done with SSL exactly the way you want to do it. The > only way that SSL knows how to carry public keys is via certificates. I would love to use certificates, but my problem with them is the following: My client installs server and client. He should be able to set them up without requesting something from 3-rd party CA. If I understand correctly, the only solution in this case would be to generate his own CA and generate certificates with it. I am not sure how much secure it would be. Also I would like to make it not too complex for end user. After installing server and client he should not perform many complex steps to make it work. Another question is: where this CA would reside: it should be stored somewhere to generate more client certificates if needed. My application is firewall management tool (www.fwbuilder.org) and daemon would run on firewall and used to configure certain aspects of it. Keeping CA there does not sound like very good idea. So I see few variants implementing this: 1. Password Server have password and keeps either whole password of MD5 of it. Clients establishes SSL connection (w/o certificates) and sends password. This is not very secure from "man-in-the-middle" attack. 2. Challenge-Response I do not know yet how to implement this. Advice appreciated. 3. Certificates After server is installed, certificate authority is generated. When using this CA, server certificate is generated. For each client, new certificate is generated using same authority. While establishing SSL connection client and server certificates are exchanged. (The question I am not completely understand yet, is how to check if they are the right ones. Probably I need to keep copy of server certificate on client side and compare one received over the connection with it?) 4. RSA keys Similar to SSH. I understand that OpenSSL protocol does not have specific support for this, so it have to be written on top of it, after SSL connection is established. I guess server have to send some token signed with its key, which client have to send back signed with its. Checking signatures would ensure identity of both. I am new to this kind of application and would really appreciate any advice. Sincerely, Vadim -- "La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever." (Antoine de Saint-Exupery) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
Use SRP (http://srp.stanford.edu) over SSL for privacy. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
Vadim Zaliva <[EMAIL PROTECTED]> writes: > On 6 Jan 2002, Eric Rescorla wrote: > > I would like to thank everybody who responded to my previous messages. > > > This can't be done with SSL exactly the way you want to do it. The > > only way that SSL knows how to carry public keys is via certificates. > > I would love to use certificates, but my problem with them is the > following: My client installs server and client. He should be able to set > them up without requesting something from 3-rd party CA. If I understand > correctly, the only solution in this case would be to generate his own CA > and generate certificates with it. I am not sure how much secure it would > be. Also I would like to make it not too complex for end user. After > installing server and client he should not perform many complex steps to It's trivial to have your softare automatically generate self-signed certificates. OpenSSL knows how. > 1. Password > > Server have password and keeps either whole password of MD5 of it. Clients > establishes SSL connection (w/o certificates) and sends password. > > This is not very secure from "man-in-the-middle" attack. Right. You need certificates on the server side to protect against MITM. > 2. Challenge-Response > > I do not know yet how to implement this. Advice appreciated. See (for instance) the mechanism in RFC 2095. > 3. Certificates > > After server is installed, certificate authority is generated. When > using this CA, server certificate is generated. For each client, new > certificate is generated using same authority. While establishing SSL > connection client and server certificates are exchanged. (The question > I am not completely understand yet, is how to check if they are the > right ones. Probably I need to keep copy of server certificate on > client side and compare one received over the connection with it?) Not quite. You set the CA as the root on the both sides and tell OpenSSL to enforce certificate verification. The tricky bit is establishing the binding between clients and their public keys in order to issue the correct certificates. This is often done with passwords. > 4. RSA keys > > Similar to SSH. I understand that OpenSSL protocol does not have > specific support for this, so it have to be written on top of it, > after SSL connection is established. I guess server have to send some > token signed with its key, which client have to send back signed with > its. Checking signatures would ensure identity of both. There's no point in doing this. Self-signed certificates are equally easy. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Beginner's questions with openssl API
Howdy, I don't have any experience in coding apps which use cryptography, but I don't want to screw up, so I come looking for some friendly advice. What I would like to do is to use the openssl simmetric crypto library to encrypt local files, and decrypt them with a user supplied passphrase. Pretty normal stuff, right? I have seen the Blowfish example in the documentation. My doubts are the following: - I gather that it's a bad idea to just encrypt all the files with the passphrase chosen by the user, right? - If so, I would encrypt the files with an internally generated pseudo-random key of the appropriate length, store it encrypted (with the user-chosen passphase as key) on disk, and then use the passphrase entered by the user to decrypt the real key and then decrypt the files with the latter. I think this is what PGP/GPG do, so it should be a better solution than just using the passphrase in the first place. Is this right? - If so, how do I get the pseudo-random data to use as a key? Just read it from /dev/random? (I am on linux.) Or is there a preferred way of doing this? - How do I use the IV value? Is this the "salt"? If so, I don't need it to decrypt the cyphertext, right? (If this is right, why does the decrypt command in the above-mentioned example (http://www.openssl.org/docs/crypto/EVP_EncryptInit.html#EXAMPLES) mention the IV value: "-iv 0102030405060708"?) Thank you for any help. As you can see, I am new to these things. Cheerio, Mack Stevenson _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Beginner's questions with openssl API
Hi Bear,
Thank you for replying.
> > - I gather that it's a bad idea to just encrypt all the files with the
> > passphrase chosen by the user, right?
>
>You don't use the passphrase *directly*, but you should certainly
>use the user's passphrase. Run it through a cryptographic hash
>and use the results as your encryption key.
Can I use either the SHA or RIPEMD-160 hashes from openssl for this purpose?
>[snip]
>Bottom line: if you're not sure what you're doing, keep it as
>simple as you possibly can. Adding features you don't understand
>is a good way to introduce fatal weaknesses.
OK.
>If you want to encrypt
>a file:
>
> - hash the passphrase to generate the key. Do not worry about
>random keys.
OK.
> - use OpenPGP packeting, but only use the literal block (which
>contains the data) and the symmetric key encrypted session
>block (which contains the encrypted literal block). Do not
>worry about the compressed block or various key blocks.
>
>- for your first cut, use hard-coded "random" data at the top
> of the SKES block. It's less secure than true random data,
> but it's one less thing for you to worry about right now.
I don't quite understand what you mean, and the man page EVP_EncryptInit(3)
isn't helping much; can't I just do it as in the example from that page:
--
EVP_CIPHER_CTX ctx;
EVP_CIPHER_CTX_init(&ctx);
EVP_EncryptInit_ex(&ctx, NULL, EVP_bf_cbc(), key, iv);
if(!EVP_EncryptUpdate(&ctx, outbuf, &outlen, intext, strlen(intext)))
{
return 0;
}
if(!EVP_EncryptFinal_ex(&ctx, outbuf + outlen, &tmplen))
{
return 0;
}
outlen += tmplen;
EVP_CIPHER_CTX_cleanup(&ctx);
--
after having set 'key' and 'iv'?
About salt/IV: how do I determine its appropriate length? And do I store it
(in plaintext) next to the encrypted file?
>But instead of asking us, the best thing to do is grabbing a copy
>of the OpenPGP spec (RFC 2440).
I shall do so. Although my interest is only in using very simple symmetric
encryption, it seems to touch on some of these issues.
There is another question I would like to pose you: suppose that I wish to
be able to determine whether the user entered the right passphrase (for
purposes other than decrypting the cyphertext). This would imply storing a
hash of the passphrase on disk, and comparing each entered passphrase to it,
right? (As Unices do.) In this context, is it still advisable to use a hash
of the passphrase as the encryption key? I understand that, for obvious
reasons, I would need to use a *different* hash algorithm (otherwise, the
decryption key would be stored as plaintext on disk all the time:-). But if
I do use a different hash algorithm, is this an acceptable approach? Or is
there a more intelligent way of doing this?
TIA,
Mack
_
Chat with friends online, try MSN Messenger: http://messenger.msn.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
>2. Challenge-Response > >I do not know yet how to implement this. Advice appreciated. The short version of how you do this is that you use some sort of hashing scheme like MD5 or SHA1. During the installation process, you generate a random password (or ask the user to enter one) and you store the password on both the server and the client. The authentication can go many ways, but the idea is for the server and client to each assure themselves that the other has the password. Here's one possible way to do it: 1) The server generates a random challenge and sends it and the current time to the client. (Lets call the server's challenge Cs and the server's time Ts.) 2) The client generates a random challenge as well and sends it and the current time (as it sees it) to the server. (Let's call the client's challenge Cc and the client's time Tc.) 3) The server computes a response by appending Cs, Ts, the password, Tc, and Cc, and sends the MD5 or SHA1 hash of this response to the client. 4) The client computes a response by appending Cc, Tc, the password, Ts, and Cs, and sends the MD5 or SHA1 hash of this response to the server. 5) Each side verifies that the other side created the correct hash, thus proving that it knows the password. This is oversimplified, I'm afraid, and is not totally secure as stated. But it should give you the idea. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA keys auth.
On Sun, Jan 06, 2002 at 01:04:37PM -0800, Vadim Zaliva wrote: > 2. Challenge-Response > > I do not know yet how to implement this. Advice appreciated. > > 4. RSA keys > > Similar to SSH. I understand that OpenSSL protocol does not have > specific support for this, so it have to be written on top of it, > after SSL connection is established. I guess server have to send some > token signed with its key, which client have to send back signed with > its. Checking signatures would ensure identity of both. I did something like this in openSSL, but had to write basic RSA enc/dec routines. Its quite straight forward with the power of OpenSSL. I used a BIO to feed my own RSA key into an RSA struct. from the ssh man pages When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the chal lenge using the private key, proving that he/she knows the private key but without disclosing it to the server. Kind Regards Crispin __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
