[zeromq-dev] Proposal for ZeroMQ certificate format

Laurent Alebarde l.alebarde at free.fr
Thu Oct 17 10:21:56 CEST 2013

My rationals are :

 1. Paranoid context where no one can trust security experts nor
    security algorithms
 2. I am not a security expert, nor my future customers
 3. I and my future customers need confidentiality, authentication in
    both ways, and integrity
 4. As a consequence, my philosophy is first to add a perpendicular
    layer of security on the security algorithms I use. "perpendicular"
    means what it is expected in math : independent, in order that by
    design, it cannot break the standard algorithm used, but will
    prevent the use of any backdoor.
 5. Second point is to keep public keys secret as far as possible, what
    makes attacks much more costly.

My use case is a SaaS with subscribed customers only, say 1,000. The 
public keys of the server and of the client will be exchanged during 
subscription, possibly under https (I have not yet investigated this part).

What I have imagined is the following :

* 	*
* 	*registration server**


	generate one key pair for all clients, dedicated to server public key 
distribution : ServerKeyForKey
*Only this public key is public*

	<--HTTPS ServerKeyForKey_pub--

	generate a key pair for this client : ServerKeyThisClient, encode it 
with ServerKeyForKey

	<--HTTPS ServerKeyThisClient_pub encoded
generate a key pair : ClientKey

	--HTTPS ClientKey_pub encoded with ServerKeyThisClient--> 	

	<--HTTPS download application and application server address--

	At this stage, both client and server knows the long term public key of 
on each other

	*application  server*

	Mechanism with confidentiality, authentication, signature, without any 
exchange of the public transcient keys in plain text

"Security through obscurity" : yes, but security does not lay on the 
secrecy of the public key. It just makes attacks more costly.

All that said, I have no experience at all with certificates. I just 
understand it enables to exchange public keys with authentication and 
integrity, and what is discussed here is confidentiality.

Le 16/10/2013 20:40, Justin Cook a écrit :
> ?Security through obscurity? I can see where you're going with this, 
> but public keys are not secure and relying on them being secret makes 
> the design a bit flaky. It's only a matter of time once a target is 
> established. Public keys are the least of worries.
> -- 
> Justin Cook
> Sent from a mobile device
> *From: *Pieter Hintjens
> *Sent: *Wednesday, 16 October 2013 19:31
> *To: *ZeroMQ development list
> *Reply To: *ph at imatix.com
> *Subject: *Re: [zeromq-dev] Proposal for ZeroMQ certificate format
> I tried to explain the use cases in my article. The goal is to send my 
> public key to you without leaking the fact. It is asymmetric.  Your 
> public key is well known but mine is not. It is a CurveZMQ usecase. 
> Anonymous clients and public servers.
> Pieter
> On Oct 16, 2013 8:23 PM, "Tony Arcieri" <bascule at gmail.com 
> <mailto:bascule at gmail.com>> wrote:
>     On Wed, Oct 16, 2013 at 9:57 AM, Laurent Alebarde
>     <l.alebarde at free.fr <mailto:l.alebarde at free.fr>> wrote:
>     > Please, keep the public key secret.
>     This is where you really need to take a step back and look at the
>     threat model.
>     Keep the public key secret from whom? You can't keep it secret from
>     someone who wants to perform a Diffie-Hellman handshake, since it's
>     one of the operands of Curve25519 scalar multiplication.
>     What is the use case for verifying the authenticity of the public key
>     in which you would also like to keep the public key secret?
>     --
>     Tony Arcieri
>     _______________________________________________
>     zeromq-dev mailing list
>     zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>     http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131017/fd7def38/attachment.htm>

More information about the zeromq-dev mailing list