Re: questions on RFC2631 and DH key agreement

- Original Message - From: Hal Finney [EMAIL PROTECTED] To: [EMAIL PROTECTED]; cryptography@metzdowd.com Sent: Sunday, February 10, 2008 9:27 AM Subject: Re: questions on RFC2631 and DH key agreement Joseph Ashwood writes: From: Hal Finney [EMAIL PROTECTED] Joseph Ashwood writes

Re: questions on RFC2631 and DH key agreement

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

Re: questions on RFC2631 and DH key agreement

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

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 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

Re: questions on RFC2631 and DH key agreement

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

Re: questions on RFC2631 and DH key agreement

- Original Message - From: Hal Finney [EMAIL PROTECTED] To: [EMAIL PROTECTED]; cryptography@metzdowd.com 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 actually recommend

Re: questions on RFC2631 and DH key agreement

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 that out,

Re: questions on RFC2631 and DH key agreement

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 protocol specification, to specify that one simply obtain an ostensibly random value, and then use

Re: questions on RFC2631 and DH key agreement

' =JeffH ' [EMAIL PROTECTED] writes: [EMAIL PROTECTED] said: http://www.xml-dev.com/blog/index.php?action=viewtopicid=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

Re: questions on RFC2631 and DH key agreement

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=viewtopicid=196 thanks, but that doesn't actually answer my first question. It only documents

Re: questions on RFC2631 and DH key agreement

- 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 establish a shared secret key between a requester

Re: questions on RFC2631 and DH key agreement

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 many of it's

Re: questions on RFC2631 and DH key agreement

' =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 X9.42

Re: questions on RFC2631 and DH key agreement

- Original Message - From: ' =JeffH ' [EMAIL PROTECTED] To: Joseph Ashwood [EMAIL PROTECTED] Cc: cryptography@metzdowd.com Sent: Monday, February 04, 2008 5:18 PM Subject: Re: questions on RFC2631 and DH key agreement I'd scrawled: If a purportedly secure protocol employing

Re: questions on RFC2631 and DH key agreement

[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

Re: questions on RFC2631 and DH key agreement

Thanks Hal. It turns out the supplied default for p is 1024 bit -- I'd previously goofed when using wc on it.. DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61EF75A2E27898B057 F9891C2E27A639C3F29B60814581CD3B2CA3986D2683705577D45C2E7E52DC81C7A171876E5CEA7

Re: questions on RFC2631 and DH key agreement

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 of it's

Re: questions on RFC2631 and DH key agreement

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

Re: questions on RFC2631 and DH key agreement

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 and

Re: questions on RFC2631 and DH key agreement

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

Re: questions on RFC2631 and DH key agreement

- Original Message - From: ' =JeffH ' [EMAIL PROTECTED] To: cryptography@metzdowd.com 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 known to both parties. So if p, q, g

questions on RFC2631 and DH key agreement

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.