> 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).
eve has to do zero computation to get at your plan-text stream. i think they call it transport security for a reason. :-) if you don't trust eve, then you can't trust /dev/truerand. in fact, why would an untrustable eve run the right exportfs? but eve doesn't need to work that hard. it gets worse. since ssl is part of a kernel device, eve gets to see your keys anyway. but eve doesn't need them. since ssl is in the kernel, eve sees the plan text side of the communication. i think the network is more of a practical worry. - erik
