Crypto DLL's/SSLeay 0.4.5
Just in case people are interested, I've put the most recent version of my SSL (SSLeay) library up on ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/ The big differece with this realease is that it builds under Windows 3.1. The DLL's for the libraries are there as well as the ported demo programs. I've used Borland C 4.0 and the .IDE file plus source code are in the distribution. The DLL's contain routines for MD2, MD5, RC4, DES (every mode you could want :-), IDEA, RSA, SSL and all the X509 etc stuff that is part of life with SSL. The library even compiled under MSDOS :-). Since my code base will always be unix first, the code is not optimised for 16bit and probably never will be, but still, the algorithms work and the code is free for comercial and non-comercial use. The applications need work to make them nice under Windows, but hell, I'm only writing a library :-). On the PGPphone issue, I Personally I feel SSLphone would be a much better way of doing things. If some-one has a 'voice' over modem program already, they should be able to slip SSL into it in only a few days. For phone over modem, authentication is not really required and what exists in my library is everything required for the encryption side of things. those URL's again http://www.psy.uq.oz.au/~ftp/Crypto/ ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps eric -- Eric Young | Signature removed since it was generating AARNet: eay@mincom.oz.au | more followups that the message contents :-)
Eric Young writes:
On the PGPphone issue, I Personally I feel SSLphone would be a much better way of doing things.
Oh, yeah? No user certificates, no way to verify whats on the other end. No assurances that you aren't being tricked into using a weak algorithm because negotiation doesn't take place under cover of signature. Lots of little potential cracks. Thanks, but no thanks. This is not to slight your code. I'm slighting the protocol. If folks want to secure links, stick to clean protocols to do the key negotiation. I'm a fan of variants of STS myself, Photuris being a biggie.
For phone over modem, authentication is not really required
And why is that? Perry
On Thu, 24 Aug 1995, Perry E. Metzger wrote:
Eric Young writes:
On the PGPphone issue, I Personally I feel SSLphone would be a much better way of doing things. Oh, yeah? No user certificates, no way to verify whats on the other end. No assurances that you aren't being tricked into using a weak algorithm because negotiation doesn't take place under cover of signature. Lots of little potential cracks. Thanks, but no thanks.
This is not to slight your code. I'm slighting the protocol. none taken, my main support for SSL is that there is minimal work to be done to make an application support encryption (+ perhaps authentication) over a connection. This means that any work done to improve the SSL
:-) Agreed, it depends on how you use SSL and implement it, I have not added it yet but I'll put in my library hooks so an application can refuse to use certain ciphers that are in the library. Currently you can specify your preference of cipher and there is a call to return the cipher being used on an SSL connection. The most recent version of SSLtelnet of ours prints the subject name of the server and the cipher being used, just so you can know if you are using RC4-40 :-). As for authentication, agreed, the key distribution problem for X509 needs work but still, if the audio is good enough, you should know who is on the other end :-). library (as in certificate distribution and verification) will instantly be able to be added to all applications using that SSL library. If each one of 15 different appliction has a different cipher/authentication package, there is 15 times the work to upgrade. Hell, to put PGP type authentication in SSL would probably not be very hard. It would require a new certificate type and a new 'verify certificate' routine and that would be about it. Basically I'm a bit lazy, I like to write libraries and then keep on reusing them.
For phone over modem, authentication is not really required And why is that? Again, if the voice is clean enough, you should know who is at the other end. If you are talking about a program being at the other end, well thats another matter :-).
eric -- Eric Young | Signature removed since it was generating AARNet: eay@mincom.oz.au | more followups that the message contents :-)
participants (2)
-
Eric Young -
Perry E. Metzger