On 1/26/06, Eugen Leitl <eugen@leitl.org> wrote:

... ----- Forwarded message from bear <bear@sonic.net> ----- Date: Thu, 26 Jan 2006 18:09:52 -0800 (PST) To: "Travis H." <solinym@gmail.com> Cc: cryptography@metzdowd.com Subject: Re: thoughts on one time pads ... The problem is that most people will not take the care needed to properly use a one-time pad. For text communications like this forum, they're great, and a (relatively) small amount of keying material, as you suggest, will last for many years.

agreed; it would be interesting to debate the bare minimum requirements for a system where pads would provide a useful improvement in security. this means all those other holes bidding malicious peers welcome need to be closed. note that unless you have a hardware entropy source generating anything more than a small amount of truly random pad is going to take a lonnnnng time. the yarrow based /dev/random in bsd is a fucking cop out; they should remove it (that is what /dev/urandom is for). fortunately VIA, AMD and Intel all provide hw rng sources of varying capability on commodity systems.

But modern applications are concerned with communicating *DATA*, not original text; someone on the system is going to want to send their buddy a 30-minute video of the professor explaining a sticky point to the class, and where is your keying material going then?

this is why i like pads for key distribution. with key material pre distributed between the endpoints that will consume it you can restrict network communication so that only authenticated traffic (from peers whom you have exchanged pads with) is allowed into higher levels of the OS stack / forwarded / applications. this is really where i see a justifiable security improvement - block all unauthenticated traffic up front, no open ports, no complex public key formats / negotiation. (it would also be interesting to see all of the potential remote exploit vulnerabilities in common IPsec key daemons) in this scenario you can still transfer your huge data archives around without consuming the entire pad with a quickness; frequent IPsec key exchange to refresh SA's leverage the security and simplicity of pads while retaining the flexibility of a chained block cipher for bulk transport.

An OTP, as far as I'm concerned, makes a really good system, but you have to respect its limits. One of those limits is a low-bandwidth medium like text-only messages, and in the modern world that qualifies as "specialized."

strong authentication and endpoint security are one of these critical components required to use a pad effectively. at a minimum i've settled on the following for managing key material and endpoint security: - bootstrap with read-only disc media prepared by a trusted peer. boot takes about 8-12 seconds for key management mode on a 1Ghz VIA proc. - passphrase protected full disk encryption with loop-AES - loop-AES key schedule on USB memory stick [two factor auth] - distinct domains / runtime instances for specific purposes. as an example, key management mode (import / export of keys, generation of pads, creation/modification of digital identity) does not even support any network capabilities in the statically linked kernel. all interaction in this domain is performed via file system with keys manually copied to external domains which are network aware or hosting services. this does mean that you're stuck using linux/bsd* for a secure domain, with grsec/lsm/selinux/pax style defenses highly suggested. ideally a capability operating system would be used, but this is a challenging problem...

Of course, the obvious application for this OTP material, other than text messaging itself, is to use it for key distribution.

yes! fixed buffer sizes, small attack surface, authentication from the first packet onward (rather than entering into a negotiation to ascertain identity). best regards, * both of these kernels need a good audit before they can be trusted (at least pertaining to the code exposed to unauthenticated attackers at a minimum), as do_brk() and bsd beacon overflows in ring0 indicate...