[19498] in cryptography@c2.net mail archive
[coderman@gmail.com: Re: [dave@farber.net: [IP] more on AP Story Justice Dept. Probing Domestic Spyin]
daemon@ATHENA.MIT.EDU (Eugen Leitl)
Tue Jan 3 13:43:08 2006
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sun, 1 Jan 2006 12:18:22 +0100
From: Eugen Leitl <eugen@leitl.org>
To: Cryptography List <cryptography@metzdowd.com>
--ei8QaAJOpV1ddsfz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
----- Forwarded message from coderman <coderman@gmail.com> -----
=46rom: coderman <coderman@gmail.com>
Date: Sat, 31 Dec 2005 18:32:33 -0800
To: Tyler Durden <camera_lumina@hotmail.com>
Cc: jya@cryptome.net, cypherpunks@jfet.org
Subject: Re: [dave@farber.net: [IP] more on AP Story Justice Dept.
Probing Domestic Spyin
On 12/31/05, Tyler Durden <camera_lumina@hotmail.com> wrote:
> ...
> Of course, NSA will likely grab&store the hidden piece as well
i would count on it, as it's a good bet the answer is yes rather than no.
> but I submit
> one might be able to make this a fairly intractable problem, particularly=
if
> information about -where- the appropriate piece is stored is itself
> destroyed. (ie, they may have the piece, but they dont know which message=
it
> belongs).
i'm working on a one time pad based IPsec key daemon with a similar
purpose to what you describe. i'll be posting here for feedback when
it's ready but the basic premise is that it provides strong ephemeral
IPsec keying using one time pads previously exchanged between peers.=20
as long as the pads are generated and secured properly[1] you don't
need to care if $TLA has kept your IPsec traffic archives in their
acres of computing machinery.
likewise, if large qubit quantum computers suddenly become feasible or
multi ring GCF gets really fast, you don't need to worry about past
key exchanges (also archived) being compromised, as with pub key based
ISAKMP implementations.
last, such a mode needs no open ports[2], so the attack surface for
remote exploitation is limited to the IP level - only authenticated
traffic is passed up the stack, everything else is dropped.
as long as your OTP's are truly random and never compromised, the key
exchange will be secure and the only way to attack your traffic
remotely will be brute force of AES256.
[1]. securing pads is really the crux of the issue here. i'm using
modified linux distributions for key generation (a host with no
networking capability - kernel omits all network functionality) and
IPsec termination (boot from CD/DVD, require USB fob / hardware token
+ passphrase for auth to access pads stored in encrypted volume).
[2]. this is true with an explanation: for the initial session ICMP
payloads are sent in the clear (not IPsec) to perform the encrypted
key exchange using OTP's. once IPsec is initialized, ICMP is also
directed through IPsec via the SPD and future rekeying uses OTP's on
top of the existing IPsec SA. i'll have more details later but in
short all traffic is authenticated or dropped, most of it
authenticated via IPsec, and the only exception being key exchange via
ICMP which is authenticated via OTP only until the first SA is
established.
the advantage of using OTP's in addition to security is simplicity:
all buffers are fixed size, key material is small (per instance) and
the operations fast (no montgomery multiplication on very large
numbers). even at a 1Hz rekey interval you could fit a years worth of
key exchange OTP in 100MBytes of storage.
the disadvantage is you probably need hardware entropy generation to
produce the pads in a reasonable time. i'm using the VIA C5XL and C5P
processors for testing / runtime and these can produce more than
enough entropy for large pads without sucking /dev/random dry.
last but not least, the implicit out of band pad exchange with trusted
peers is reasonable for private group networking and other smaller
networks but would be very difficult to scale to a large organization.
this is a feature in my eyes, as private group networks are what this
is intended for and meatspace pad exchange a desired requirement to
ensure trust is properly placed.
----- End forwarded message -----
--=20
Eugen* Leitl <a href=3D"http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
--ei8QaAJOpV1ddsfz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDt7p+dbAkQ4sp9r4RAhCEAJ9K0vwRFArzlPyPPI5QQfr8Yh2ODwCeIO5i
sU2qh1vunirVETuwTgOYzaA=
=dNbc
-----END PGP SIGNATURE-----
--ei8QaAJOpV1ddsfz--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
