On Mon, 11 Aug 2014, Nicholas Wilson wrote:
> Hi Ingo,
>
> On 10 August 2014 15:54, Ingo Schwarze <[email protected]> wrote:
> > Portability goo clutters code and reduces readability, and hence
> > endangers correctness and security ...
> > Making a portable version is *impossible*
> > without some clutter (even though the portability goo in OpenBSD
> > sub-projects is often less heavy than the clutter you find in some
> > other project's master repos).
>
> I understand the reasoning, but for LibreSSL it seems a shame since
> the portable "goo" is so minimal. Unlike OpenSSH, which has by
> necessity tons of hooks for platform behaviour, the only changes so
> far in LibreSSL portable are adding an implementation of OpenBSD
> functions like getentropy(), and some headers. Having those platform
> implementations sitting there in a "compat" directory doesn't make it
> harder to audit the code, does it?
>
> Oh well! The project will work it out if it becomes a common problem.
>
> My main question is still unanswered, namely what the ideas are for
> the API exposing the RSA PSS/OAEP MGF1 hash. Should I send in a patch
> porting over the OpenSSL 1.0.2 API for it?
Which API are you referring to? You are certainly welcome to send a diff - I
cannot guarantee that it will be committed, however we would certainly review
and consider it.
> Better, I'd ideally like to
> split out libcrypto into more modular components so that LibreSSL can
> be used without all the horrific layers of goo (ECDH_METHOD structure
> and other useless clutter!). The OpenSSL API goo can remain as a way
> to access the underlying crypto functions, but the internal API should
> be cleaner. I'd be interested in making those changes for the RSA and
> EC code.
At this stage our primary approach is to maintain API compatiability (as far
as possible) with OpenSSL. That said, I have been pondering an easy to use
and robust interface for ed25519. If you came up with an API that was
consistent/clean and worked for both ed25519 and RSA-PSS, then I'd certainly
be interested. That said, we would probably look at providing the OpenSSL API
as a wrapper around the cleaner API.
--
"Stop assuming that systems are secure unless demonstrated insecure;
start assuming that systems are insecure unless designed securely."
- Bruce Schneier
