[zeromq-dev] Certificate formats

T. Linden tlinden at cpan.org
Thu Oct 10 17:40:51 CEST 2013


On Thu, Oct 10, 2013 at 04:05:04PM +0200, Pieter Hintjens wrote:
> Tom, you are focussing on secret keys here, but we also need to
> exchange public keys safely, right?

Well, as the name implies they're public and worthless for an attacker
(at least as I understand EC). 
 
> Can you comment on public keys + metadata? Encrypted or not? Safe to
> paste into email?

You could encrypt them as well, I think it depends on the application,
if they are considered to remain secret as well. But if you encrypt the
public key, you'll need another private key to do so.

To clarify, this is, how I currently encrypt the private key:

- user enters password
- a hash is generated from it (128.000 times recursively)
- the result is turned into a curve25519 secret key
- the private key will then encrypted using secret_box() and the derived
  secret key from above.

So, let's say, you've got a client who generates a keypair and the client
shall encrypt the public key. The receiver (the server operator) must be
able to decrypt it, so the client would need the private key of the
server. This could be keys just for this purpose (aka "key exchange
keys"), but they have to be transmitted as well. But how do you transmit
this private key to the client in a safe way? Usually encrypted. That's
a chicken/egg loop.

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.

But maybe I'm wrong.




best regards,
Tom

-- 
    PGP Key: https://www.daemon.de/txt/tom-pgp-pubkey.txt
S/Mime Cert: https://www.daemon.de/txt/tom-smime-cert.pem
 Bitmessage: BM-2DAcYUx3xByfwbx2bYYxeXgq3zDscez8wC

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the zeromq-dev mailing list