Hullo 9fans. Can somebody please explain to my slow mind the purpose of this game in /sys/src/cmd/exportfs/exportfs.c (and the corresponding half in cmd/import.c) and where my thoughts on it derail ?
/* exchange random numbers */
srand(truerand());
for(i = 0; i < 4; i++)
key[i+12] = rand();
if (initial)
fatal("Protocol botch: old import\n");
if(readn(netfd, key, 4) != 4)
fatal("can't read key part; %r\n");
if(write(netfd, key+12, 4) != 4)
fatal("can't write key part; %r\n");
truerand() returns (at most) 32 bits of entropy, which gets pushed into
srand() and then 32 bits of entropy are read back out... why not just use
truerand() directly?
But wait...
We haven't brought up SSL yet, so Eve can read our exchanged random
numbers... now these values get shoved into SHA-1 (along with the 56 bits of
entropy from Kn derived from p9any authentication) before being used to make
the SSL secrets... but... that doesn't seem to matter much. Eve sees the
first four, the last four, and knows 1/8th of the middle 8 bytes (p9sk1 gets
an 8-byte secret by unpacking a 7-byte DES key) of the input to the SHA-1
function, meaning... Eve still only needs to do at most 2^56 SHA-1
operations to search for our SSL secrets [1]... OK, so Eve can't have
precomputed tables to help her out, fair enough, but this still seems
dubious.
Subsequently, having done all of this, the secrets fed into the SSL stream
contain only 80 bits of entropy, which is itself somewhat small (esp.
relative to the ability of rc4 to use 128 or even 256 bit keys).
Am I missing something obvious?
--nwf;
[1] In fact, since Eve knows the first four bytes of the input, she can run
a reduced version of SHA-1 having precomputed the state of the machine after
the first four rounds (leaving only 76 more to go).
pgpjBe7Z0hmFE.pgp
Description: PGP signature
