9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Nathaniel W Filardo <nwf@cs.jhu.edu>
To: 9fans@9fans.net
Subject: [9fans] exportfs security question
Date: Fri, 10 Apr 2009 04:41:02 -0400	[thread overview]
Message-ID: <20090410084102.GG4823@masters6.cs.jhu.edu> (raw)

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

             reply	other threads:[~2009-04-10  8:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-10  8:41 Nathaniel W Filardo [this message]
2009-04-10 10:25 ` Steve Simon
2009-04-10 15:18   ` Nathaniel W Filardo
2009-04-10 11:48 ` erik quanstrom
2009-04-10 12:08   ` Mechiel Lukkien
2009-04-10 15:17     ` Nathaniel W Filardo
2009-04-11 23:24 ` Russ Cox
2009-04-13  4:45   ` lucio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090410084102.GG4823@masters6.cs.jhu.edu \
    --to=nwf@cs.jhu.edu \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).