From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <679b27481fefe8cdfa8b7838625ee32b@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 10 Apr 2009 07:48:54 -0400
To: 9fans@9fans.net
In-Reply-To: <20090410084102.GG4823@masters6.cs.jhu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] exportfs security question
Topicbox-Message-UUID: d94e4178-ead4-11e9-9d60-3106f5b1d025

> 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