- Original Message -
From: ""Hal Finney"" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Sent: Sunday, February 10, 2008 9:27 AM
Subject: Re: questions on RFC2631 and DH key agreement
Joseph Ashwood writes:
From: ""Hal Finney"" &l
Joseph Ashwood writes:
> From: ""Hal Finney"" <[EMAIL PROTECTED]>
> > Joseph Ashwood writes, regarding unauthenticated DH:
> >> if b uses the same private key
> >> to generate multiple yb the value of b will slowly leak.
> >
> > I'm not familiar with this last claim, that the value of b's private k
> > E.g., here's such a specfication excerpt and is absolutely everything said
> > in
> > the spec wrt obtaining said signature keys:
> >
> > When generating MAC keys, the recommendations in [RFC1750] SHOULD be
> > followed.
>
> One point, RFC1750 has been superceded by RFC4086.
I'll point t
[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>;
Sent: Thursday, February 07, 2008 2:17 PM
Subject: Re: questions on RFC2631 and DH key agreement
I think I already know the answer to this question, but I just want to test
my
understanding...
How wise (in a real-world sense) is it, in a pr
- Original Message -
From: ""Hal Finney"" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Sent: Wednesday, February 06, 2008 8:54 AM
Subject: Re: questions on RFC2631 and DH key agreement
Joseph Ashwood writes, regarding unauthenticated DH:
I would ac
Hi Jeff -
> How wise (in a real-world sense) is it, in a protocol specification, to
> specify that one simply obtain an ostensibly random value, and then use that
> value directly as the signature key in, say, an HMAC-based signature, without
> any further stipulated checking and/or massaging of
Jeff Hodges wrote:
> Thanks for your thoughts on this Hal. Quite educational.
>
> > Jeff Hodges wrote:
> > > It turns out the supplied default for p is 1024 bit -- I'd previously
> > > goofed
> > > when using wc on it..
> > >
> > > DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
I think I already know the answer to this question, but I just want to test my
understanding...
How wise (in a real-world sense) is it, in a protocol specification, to
specify that one simply obtain an ostensibly random value, and then use that
value directly as the signature key in, say, an HM
Thanks for your thoughts on this Hal. Quite educational.
> Jeff Hodges wrote:
> > It turns out the supplied default for p is 1024 bit -- I'd previously
> > goofed
> > when using wc on it..
> >
> > DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61EF75A2E27898B057
> > F9891C2E27A639
Jeff Hodges wrote:
> It turns out the supplied default for p is 1024 bit -- I'd previously goofed
> when using wc on it..
>
> DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61EF75A2E27898B057
> F9891C2E27A639C3F29B60814581CD3B2CA3986D2683705577D45C2E7E52DC81C7A171876E5CEA7
> 4B1448BF
Joseph Ashwood writes, regarding unauthenticated DH:
> I would actually recommend sending all the public data. This does not take
> significant additional space and allows more verification to be performed. I
> would also suggest looking at what exactly the goal is. As written this
> provides no
Jeff Hodges writes:
> If a purportedly "secure" protocol employing a nominal DH exchange in order
> to
> establish a shared secret key between a requester and responder, employs
> widely known published (on the web) fixed values for g ("2") and p (a
> purportedly prime 1040 bit number) for many
Thanks Hal.
It turns out the supplied default for p is 1024 bit -- I'd previously goofed
when using wc on it..
DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61EF75A2E27898B057
F9891C2E27A639C3F29B60814581CD3B2CA3986D2683705577D45C2E7E52DC81C7A171876E5CEA7
4B1448BFDFAF18828EFD2519
[EMAIL PROTECTED] said:
> *nix /dev/urandom should work well, the entropy harvesting is reasonably
> good, and the mixing/generating are sufficient to keep it from being the
> weak link.
yeah, that's the way it sounds from the man page (on linux). thx.
> Actually I'm saying that if p and g do
- Original Message -
From: "' =JeffH '" <[EMAIL PROTECTED]>
To: "Joseph Ashwood" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, February 04, 2008 5:18 PM
Subject: Re: questions on RFC2631 and DH key agreement
I'd scrawled:
> If a purportedly
' =JeffH ' <[EMAIL PROTECTED]>
>[EMAIL PROTECTED] said:
>> I'm going to approach the answer somewhat differently: Why are you using
>>this mechanism?
>
>Are you referring to the above mentioned mechanism of arriving at the ZZ
>value independently, which is implied in RFC2631?
I'm referring to the
I'd scrawled:
> > If a purportedly "secure" protocol employing a nominal DH exchange in
> > order to
> > establish a shared secret key between a requester and responder, employs
> > widely known published (on the web) fixed values for g ("2") and p (a
> > purportedly prime 1040 bit number) for man
Ok thanks, I'm going to risk pedanticism in order to nail things down a bit
more rigorously..
' =JeffH ' <[EMAIL PROTECTED]> writes:
>>[EMAIL PROTECTED] said:
>> http://www.xml-dev.com/blog/index.php?action=viewtopic&id=196
>>
>>thanks, but that doesn't actually answer my first question. It only
' =JeffH ' <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] said:
>> http://www.xml-dev.com/blog/index.php?action=viewtopic&id=196
>
>thanks, but that doesn't actually answer my first question. It only documents
>that a and b (alice and bob) arrive at the ZZ value independently. My question
>is actua
- Original Message -
From: "' =JeffH '" <[EMAIL PROTECTED]>
Sent: Saturday, February 02, 2008 12:56 PM
Subject: Re: questions on RFC2631 and DH key agreement
If a purportedly "secure" protocol employing a nominal DH exchange in
order to
est
I'd scrawled..
> Other than for b perhaps wanting to verify the correctness of { p, q, g,
> j } ("group parameter validation"), is there any reason to send q ?
[EMAIL PROTECTED] replied:
> I would actually recommend sending all the public data. This does not take
> significant additional space
- Original Message -
From: "' =JeffH '" <[EMAIL PROTECTED]>
To:
Cc: "' =JeffH '" <[EMAIL PROTECTED]>
Sent: Friday, February 01, 2008 1:53 PM
Subject: questions on RFC2631 and DH key agreement
(ya and yb) if { p, q, g, j } are k
Oh, yeah, sorry, your diagram (or whoever drew it) does in fact answer my
second question wrt what one needs to send over the wire wrt a simplistic DH
profile. Just g, p, and a public key (y).
thanks again,
=JeffH
-
The Cryp
[EMAIL PROTECTED] said:
> http://www.xml-dev.com/blog/index.php?action=viewtopic&id=196
thanks, but that doesn't actually answer my first question. It only documents
that a and b (alice and bob) arrive at the ZZ value independently. My question
is actually concerning section 2.1.2 "Generation
http://www.xml-dev.com/blog/index.php?action=viewtopic&id=196
On 2/1/08, =JeffH <[EMAIL PROTECTED]> wrote:
>
> So AFAICT from perusal of RFC2631 "Diffie-Hellman Key Agreement Method" and
> RFC2630 CMS, when one executes a simple DH static profile between two parties,
> the only things that reall
So AFAICT from perusal of RFC2631 "Diffie-Hellman Key Agreement Method" and
RFC2630 CMS, when one executes a simple DH static profile between two parties,
the only things that really need to go over the wire are each party's public
keys (ya and yb) if { p, q, g, j } are known to both parties. A
26 matches
Mail list logo
