On Thu, Oct 10, 2013 at 5:40 PM, T. Linden <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
