<br><font size=2 face="sans-serif">Thank you very much! Exactly what I
was looking for.</font>
<br>
<br><font size=2 face="sans-serif">Hav a nice day.</font>
<br><font size=2 face="sans-serif">Oliver<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Matt Johnston <matt@ucc.asn.au></b>
</font>
<p><font size=1 face="sans-serif">14.09.2007 17:21</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">An</font></div>
<td><font size=1 face="sans-serif">oliver.hanka@gi-de.com</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Kopie</font></div>
<td><font size=1 face="sans-serif">dropbear@ucc.asn.au</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Thema</font></div>
<td><font size=1 face="sans-serif">Re: Two questions regarding Diffie-Hellman
key exchange</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>On Fri, Sep 14, 2007 at 05:11:46PM +0200, oliver.hanka@gi-de.com
wrote:<br>
> Hello,<br>
> <br>
> I am currently working on my master-thesis, which involves implementing
<br>
> the SSH protocol on a smart-card. Therefore I am using dropbear as
a non <br>
> cpu and memory intensiv blueprint.<br>
> <br>
> I am currently stucked with two questions regarding the Diffie-Hellman
key <br>
> exchange (SSH_MSG_KEXDH_INIT message). First of all, can you point
me to a <br>
> document where the prime number p (128Byte) is defined? Unfortunatly
the <br>
> RFC 4253 (SSH Transport Layer) doesn't give a hint.<br>
<br>
Take a look at section 6.2 of RFC 2409. The naming is a bit<br>
of a shambles - I'm not sure why diffie-hellman-group1-sha1<br>
actually refers to "Second Oakley Group".<br>
<br>
> The next question I am puzzled with: How come the result (e) of the
client <br>
> side 'e = g^x mod p' calculation is a 133 Byte value? At least, that's
<br>
> what it looks like when I sniff the packet with wireshark (formaly
<br>
> ethereal). From my understanding, a modulo calculation with a 128
byte <br>
> value should produce a result equal or less than 128 byte. Am I wrong?<br>
> Are there additional bytes added to e, which the RFC 4253 doesn't
mention? <br>
> (the message is described in section 8, RFC 4252, jan 2006)<br>
<br>
Have a look at section 5, rfc4251. mpints have a 4 byte<br>
lengthh, then may be padded by a byte if their most<br>
significant bit is set.<br>
<br>
Cheers,<br>
Matt<br>
<br>
</font></tt>
<br>