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 :
*client**
* *
* *registration server**
*
*Registration*
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
*Use*
*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: *[email protected]
*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" <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Oct 16, 2013 at 9:57 AM, Laurent Alebarde
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
