Re: Freedomphone (fwd from [email protected])

----- Forwarded message from "Ralf-P. Weinmann" <[email protected]> -----

From: "Ralf-P. Weinmann" <[email protected]>
Date: Fri, 21 Nov 2003 01:40:33 +0100
To: Steve Schear <[email protected]>
Cc: [email protected]
Subject: Re: Freedomphone

On Wed, Nov 19, 2003 at 12:59:36PM -0800, Steve Schear wrote:
> At 01:39 PM 11/19/2003 -0500, Jack Lloyd wrote:
> > > > "We allow everyone to check the security for themselves, because
> > > > we're the only ones who publish the source code," said Rop Gonggrijp
> >
> >"We are currently performing a internal round of reviews with a expert
> >group of security researchers and cryptographers. Depending on the results
> >of this review and the time it takes us to implement the relevant
> >recommendations, our current plan is to have the Source available for
> >Download: 23.11.2003" (http://www.cryptophone.de/html/downloads_en.html)
> >
> >We'll see.
> 
> If and when this is accomplished the source could then be used, if it can't 
> already, for PC-PC secure communications.  A practical replacement for 
> SpeakFreely may be at hand.  The limitation of either direct phone or ISDN 
> connection requirement is a problem though.

>From what I've gathered from the diagrams in [1], it seems to be using AES-256
in counter-mode XORed together with Twofish counter-mode output, Twofish also
being keyed with a 256 bit value. I sense paranoia here - but being paranoid
myself sometimes I very much welcome this decision! Those two keys are derived
by means of SHA-256 from the DH key exchange for which a 4096 bit modulus.
Neat.

The only thing I can't see clearly in the diagram is the authentication of the
DH exchange. Maybe this is the third SHA-256 hash which goes back to "User" ?

Hmm.. Does this mean the users have to read of SHA-256 hash values to each
other after the connection has been established? Oh. Right. It says "Readout
hash based key authentication" on the left hand side of the spec. Dunno whether
I like that. There should be a means to cache credentials after an initial
trust relationship between communicating parties has been established. But from
what I understand, this type of scheme is exactly what the implementors wanted
to avoid.

Cheers,
Ralf

[1] GSMK CryptoPhone 100 technical specifications
    http://www.cryptophone.de/downloads/gsmk100.pdf

-- 
Ralf-P. Weinmann <[email protected]>
PGP fingerprint: 1024D/EF114FC02F150EB9D4F275B6159CEBEAEFCD9B06

----- End forwarded message -----
-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/veWAdbAkQ4sp9r4RAr3yAJ9vcnkh48SgQoZ1Tu7SNajNJtgwwACeIVl1
jJqf0EN7fPmCQ0g9k2DXmOU=
=3d3V
-----END PGP SIGNATURE-----