minssl
Software
www.skarnet.org
This page will be regularly updated as minssl usage increases.
As long as you correctly install the required packages and set up the
needed dependencies in conf-compile, you shouldn't have any
problem in building minssl.
There is, however, one thing to know about dependencies: the
nistp224 package, version
0.75, will not compile with gcc 3, failing the test
suite. A bug-report has been sent to the nistp224 author.
For now, please compile nistp224 with gcc-2.95.3.
I have a separate page detailing how to set up minssl-tunneled versions of existing services.
No. Client authentication is a completely different problem, with multiple solutions, and it is not minssl's job to address it. For instance, the checkpassword interface is a way to perform password-based client authentication.
I plan to write some public key cryptography-based client authentication software in the near future, using nistp224 and kcdsa224; it will probably be released as a separate package.
I can only warrant that I have done my best to ensure that minssl is as secure as possible. But one of the following may happen:
The first two cases are bound to the state of the art in cryptographic research. The probability of the third and fourth cases will diminish over time with peer review, and in a few releases I should be able to offer a cash guarantee as Dan Bernstein does with qmail and djbdns. I'm already fairly confident that minssl is not weaker than the algorithms it uses, and that it contains no security holes.
See Louis Granboulan's paper named PECDSA for a detailed comparison of existing El Gamal-like digital signature schemes. This paper shows that EC-KCDSA is a better standard than ECDSA both security-wise and computationally-wise. The Schnorr scheme is even better; unfortunately, it is patented.
Go ahead and do some performance tests. Send me your /package/prog/skalibs/sysdeps/sysdeps file, your complete test suite and test protocol, and your results. I will add performance notes here over time.
Not as far as I know.
minssl uses only unpatented algorithms, or algorithms on which existing patents are invalid. (This happens more often that you would think.) Check the nistp224 patent page for more information.
minssl is being developed in, and available from, France: so U.S.A. export
control, of course, does not apply. French export control does apply,
though: minssl is in the process of being approved by the French government,
which may take up to four months.
Once the approval has been given, minssl will be entirely trouble-free
on my side, i.e. providing and exporting the software from France.
To be sure that it is trouble-free on your side, check your
country's law on importing and using cryptographic software.
Yes.
The hash127 and nistp224 libraries, included in parts of the minssl suite, are not "free" or "open source". But, as usual with Dan Bernstein's software, it means that you are not allowed to redistribute modified versions of the software. As long as you build the minssl binaries with the pristine hash127 and nistp224 libraries, there is no problem.
I am responsible for minssl's behaviour. The authors of external libraries are not. If you find a bug, report it to me - DJB would be very angry, and rightly so, if you wasted his time with minssl questions on the pretense that minssl uses hash127 and nistp224.
On the other hand, if you distribute a modified minssl version, then you are responsible for it, and I do not want to hear one complaint about it. I will not provide support for minssl binaries, nor minssl modified versions. In particular, you should try and understand the /package convention benefits, and not modify minssl to make it follow the FHS - or any other poor standard. If you modify minssl, you are on your own, and I will take all credit - as stated by the BSD licence - and no blame.
One word: modularity. minssl does its job, no more, no less. I don't like the idea of reimplementing the wheel in every piece of software that I produce. Some existing programs already do what I need: I use them. The cost is a lot of dependencies, but the advantages far outweigh that cost.
Deal with it. ucspi-tcp and daemontools are excellent software, they're reliable, they do what I need - and what you need, too -, they are almost free software (the only thing you can't do is distribute modified versions), they really help system administrators and programmers alike, and they teach a way of using and designing software that people can only benefit from learning. There is no reason, apart from religious belief, why you should not use them; and your religious beliefs are your own problems, not mine.
However, there are free / open source software alternatives that perform some of the needed functionality: