On Thu, Oct 17, 2013 at 09:40:01PM +0200, Pieter Hintjens wrote:
> > Nice, glad we're clear now ;)
>
> We're not quite finished. There's a confusion (also for me) between
> the public key used for encrypting the certificate content, and the
> public key provided in the content itself.
Usually you
On Thu, Oct 17, 2013 at 7:33 PM, Tony Arcieri wrote:
> Nice, glad we're clear now ;)
We're not quite finished. There's a confusion (also for me) between
the public key used for encrypting the certificate content, and the
public key provided in the content itself.
These are two separate layers (
On Wed, Oct 16, 2013 at 11:59 PM, Pieter Hintjens wrote:
> Tony,
>
> I realized what you are explaining. It's impossible to decode the
> certificate without the sender's public key anyhow, so it has to be
> sent in clear.
>
Nice, glad we're clear now ;)
> So this brings us to a public key form
p...@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.
Anon
Tony,
I realized what you are explaining. It's impossible to decode the
certificate without the sender's public key anyhow, so it has to be
sent in clear.
So this brings us to a public key format which is Box
[metadata](C'->S), where C and the nonce used are clear-text headers.
And then the finge
On Wed, Oct 16, 2013 at 6:06 PM, crocket wrote:
> A digest might save network bandwidth in exchange for more CPU usage.
>
No, you cannot perform Curve25519 scalar multiplication without the full
public key. And again, we're talking about 256-bits here. The reason key
fingerprints exist in the fi
A digest might save network bandwidth in exchange for more CPU usage.
On Thu, Oct 17, 2013 at 5:40 AM, Tony Arcieri wrote:
> On Wed, Oct 16, 2013 at 11:31 AM, Pieter Hintjens
> wrote:
> > I tried to explain the use cases in my article. The goal is to send my
> > public key to you without leaki
On Wed, Oct 16, 2013 at 11:31 AM, Pieter Hintjens wrote:
> I tried to explain the use cases in my article. The goal is to send my
> public key to you without leaking the fact.
That doesn't explain under what circumstance someone going to
authenticate a public key without immediately using it for
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.
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" wrote
On Wed, Oct 16, 2013 at 9:57 AM, Laurent Alebarde 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 handsha
Nice !
Le 16/10/2013 19:11, Pieter Hintjens a écrit :
On Wed, Oct 16, 2013 at 6:57 PM, Laurent Alebarde wrote:
Please, keep the public key secret.
Indeed...
So here's my last proposal before I quit for the day :-)
We use the full SHA512 hash, keeping the public key and metadata
secret and
On Wed, Oct 16, 2013 at 6:57 PM, Laurent Alebarde wrote:
> Please, keep the public key secret.
Indeed...
So here's my last proposal before I quit for the day :-)
We use the full SHA512 hash, keeping the public key and metadata
secret and boxed for the recipient.
We print the full 64-byte sign
Please, keep the public key secret.
Le 16/10/2013 18:54, Pieter Hintjens a écrit :
On Wed, Oct 16, 2013 at 6:37 PM, Tony Arcieri wrote:
Or, alternatively, display the public key itself
We could do that. This does expose the public key though, which up to
now has been secret (so an attacker
On Wed, Oct 16, 2013 at 6:37 PM, Tony Arcieri wrote:
> Or, alternatively, display the public key itself
We could do that. This does expose the public key though, which up to
now has been secret (so an attacker cannot track who is sending
certificates to a server).
-Pieter
__
On Wed, Oct 16, 2013 at 9:36 AM, Tony Arcieri wrote:
> You should still provide a secure digest for authenticating public keys.
Or, alternatively, display the public key itself
--
Tony Arcieri
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
ht
On Wed, Oct 16, 2013 at 6:21 AM, Pieter Hintjens wrote:
> - a more secure hash, which we must truncate to fit the use case, e.g.
> first 6 bytes of SHA512 hash
6 bytes does not provide a sufficient security margin for key
verification. This is still well within the realm of a brute force
search.
I was kind of hoping the bike shedding would go on for a few more days. :-P
cr
On Oct 16, 2013, at 9:12 AM, shancat wrote:
> > I suggest we use SHA512 truncated to 6 bytes, and prefixed by the
> > first 6 bytes of the sender's public key. To create a fraudulent
> > certificate an attacker would
> I suggest we use SHA512 truncated to 6 bytes, and prefixed by the
> first 6 bytes of the sender's public key. To create a fraudulent
> certificate an attacker would have to find a double collision.
Very good idea, I agree with this entirely.
___
zeromq
On Wed, Oct 16, 2013 at 3:40 PM, shancat wrote:
> Point 1 & 3 should be excluded. Why bother with high strength crypto like
> curve when it's easy to generate forged certificates in the first place?
It's not clear that it's easy or even possible. A forged certificate
would need to have the exact
What I said but in nicer words :) I think the question is whether truncated
SHA512 has a potential to be easily collided? Integrity is desirable in
this case (I think) because we want integrity of the certificate.
On Oct 17, 2013 12:48 AM, "Laurent Alebarde" wrote:
> As far as I know, Git does n
As far as I know, Git does not deal with security but integrity. SHA-1
is used there, as a hash only instead of file names, to allow for file
renames & moves with respect to a similarity index.
The fair hypothesis is that in the same repository, the chance of
collision are too low to be consid
Point 1 & 3 should be excluded. Why bother with high strength crypto like
curve when it's easy to generate forged certificates in the first place?
2 needs to be analysed a bit more. I think Git does something very similar
but in that case it's probably to guard against repo corruption not
determin
http://en.wikipedia.org/wiki/Public_key_fingerprint is relevant and
describes the use case and vulnerabilities accurately.
We have, I think, three options:
- MD5 fingerprinting, with the risk of collisions
- a more secure hash, which we must truncate to fit the use case, e.g.
first 6 bytes of SHA
On Wed, Oct 16, 2013 at 2:58 PM, Laurent Alebarde wrote:
> If you put two fingerprints aligned in two lines, it takes less than a
> second to see if they differ or not, whatever is the lengh, even 256 bytes.
Yes, if you see both on the same screen. But then of course you can
compare the two enti
On Wed, Oct 16, 2013 at 01:59:54PM +0200, Pieter Hintjens wrote:
> However I'm not convinced we can ignore manual verification. If I send
> you my public key and then call you to check whether you got it, how
> are you going to tell me what you got?
Well, that's an argument.
Then what about some
If you put two fingerprints aligned in two lines, it takes less than a
second to see if they differ or not, whatever is the lengh, even 256 bytes.
The brain is a nice piece of work.
Le 16/10/2013 13:59, Pieter Hintjens a écrit :
On Wed, Oct 16, 2013 at 1:51 PM, T. Linden wrote:
So, I don't
On Wed, Oct 16, 2013 at 1:51 PM, T. Linden wrote:
> So, I don't think it makes a big difference if the fingerprint is 32 or
> 64 bytes long. No user in the real world would read it anyway. Usually a
> piece of software would do the job of fingerprint comparing.
If we agree on this as the use cas
> I'll let you read the article first. The confidentiality is one issue,
> fingerprinting is another.
A side note about the fingerprint: I'm not sure if the purpose of it is
to be recognizable by humans. Taking your ssh example: if the
fingerprint of the server key changes, the ssh client warns th
I'll let you read the article first. The confidentiality is one issue,
fingerprinting is another.
On Tue, Oct 15, 2013 at 8:30 PM, Tony Arcieri wrote:
> On Tue, Oct 15, 2013 at 11:28 AM, Pieter Hintjens wrote:
>>
>> The key itself may be encrypted; there may also be metadata that is
>> also encr
On Tue, Oct 15, 2013 at 11:28 AM, Pieter Hintjens wrote:
> The key itself may be encrypted; there may also be metadata that is
> also encrypted. The goal is to allow verification out of band that the
> entire package wasn't replaced by a fraudulent version en-route.
If your goal is to keep the
On Tue, Oct 15, 2013 at 8:12 PM, Tony Arcieri wrote:
>> While I'm not defending MD5 at all, can a forgery m' have the same size as
>> m?
> Yes.
That's a problem then... the verification line has the content length
+ signature; easy to check if the content has been padded. But if one
can create a
On Tue, Oct 15, 2013 at 10:59 AM, Pieter Hintjens wrote:
> While I'm not defending MD5 at all, can a forgery m' have the same size as
> m?
>
Yes.
As far as I can see, the signature has to be short enough to verify by
> hand. SHA256 would produce 32 bytes; just the same as verifying the
> CURVE
While I'm not defending MD5 at all, can a forgery m' have the same size as m?
As far as I can see, the signature has to be short enough to verify by
hand. SHA256 would produce 32 bytes; just the same as verifying the
CURVE key by hand.
On Tue, Oct 15, 2013 at 7:22 PM, Tony Arcieri wrote:
> On Mo
On Mon, Oct 14, 2013 at 6:16 AM, Pieter Hintjens wrote:
> Nonetheless, I used MD5. The assertion is that collisions do not
> matter here. I may be wrong.
>
Collisions definitely matter here. What you're specifically worried about
is second preimage resistance, that is: given m, find m' such that
I almost feel that explaining is spoiling the fun. Obviously I wanted
to use SHA512 because it's more secure, and already in libsodium.
Nonetheless, I used MD5. The assertion is that collisions do not
matter here. I may be wrong.
SHA512 generates a 64-byte hash. That is not usable as a human
read
On Mon, Oct 14, 2013 at 02:57:22PM +0200, Laurent Alebarde wrote:
> Why do you want to use deprecated MD5, even if you use it in a secure
> way?
I agree, it would be better, to use SHA512. In addition it's already
implemented in libsodium (nacl): crypt_hash().
best regards,
Tom
--
PGP Ke
Hi Pieter,
Why do you want to use deprecated MD5, even if you use it in a secure
way ? However valid are your arguments, that's still deprecated MD5.
Users won't dig in your arguments, or probably they don't have the
skills to do so, but they will see it is still MD5, what puts trouble in
one
Hi all,
I've posted a proposal for a certificate format at http://hintjens.com/blog:62.
This is not yet an RFC draft, but meant to drive the discussion
forwards. It's a text format split into two layers; a generic
"envelope" format that delivers opaque frames (sound familiar?) and a
per-mechanism
39 matches
Mail list logo
