[zeromq-dev] Certificate formats

Pieter Hintjens ph at imatix.com
Thu Oct 10 18:06:51 CEST 2013


On Thu, Oct 10, 2013 at 5:40 PM, T. Linden <tlinden at cpan.org> wrote:

> Well, as the name implies they're public and worthless for an attacker
> (at least as I understand EC).

They don't need to be secret but they do have to be authentic, and
serialized on disk, and exchanged. So a file format of some kind,
possibly signed to prevent tampering.

> To clarify, this is, how I currently encrypt the private key:
> - user enters password
> - a hash is generated from it (128.000 times recursively)

What does that do?

> So, IMHO something like the current zcert format, in unencrypted form,
> should be sufficient to transmit public keys. In the real world you
> would transmit them over another - secure - channel anyway.

Right. Signing or encrypting a public key becomes problematic.
However, secure channels are rare things these days and I don't like
simply delegating the issue since it's the major vulnerability in our
design.

I'd thought of doing this asymmetrically for at least the classic
client-server use case that covers 80% of our use cases:

* server public key is provided in a truly public fashion (and can be
verified as such)
* clients generate their own keys and encrypt them to the server's secret key
* clients can then send their public keys safely to the server, no-one
else can decrypt them

It's vulnerable to an imposter guessing meta-data and creating
fraudulent keys to imitate a client. However a MIM attack will fail,
since an imposter cannot create valid HELLO nor WELCOME messages. (I
think, but a triple check here would be good).

So this gives us three variants:

* "public": clear text public certificate, for server
* "client": authenticated and encrypted client public certificate
* "secret": encrypted secret certificate, for server or client

I'd rather have a single format for all variants. It means one parser.

-Pieter



More information about the zeromq-dev mailing list