On 12/31/05, Tyler Durden 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. 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.

Yes...I thought about a one-time pad approach. I'm not well read enough to say whether what I've described technically counts as a one time pad, but it seems to have many similarities to what you're talking about. A "weakness" is that if the "message" is intercepted and deencrypted, the interceptor (is this Alice?) could then retrieve the message. HOWEVER, they must retrieve the message in a short amount of time, possibly even hours, UNLESS Alice & friends can core-dump the entire probable network and, somehow, (later if they wish by appropriate Network Clock monkeying) find within it the stored other pieces of the message. I suspect that this problem can be made intractable even to Quantum computers, but don't quote me on that. No doubt they've thought of this scenario, so be on the lookout for little hooks. Another nice thing is that they CAN'T always rubber-house it out of you: Even you can't get it if they've beaten you're keyboarding hands so badly you can't access it within the alotted time. (Of course, the "message" can tell you how much time you've got before the other network-clouded pieces expire). Oh, and the usual games of fake messages should apply, but in this case there are some advantages to having some universally. network-enabled "default" messages. (And if you hit one of -those- messages, the real message should be destroyed automatically.) -TD

From: coderman To: Tyler Durden CC: jya@cryptome.net, cypherpunks@jfet.org Subject: Re: [dave@farber.net: [IP] more on AP Story Justice Dept. Probing Domestic Spyin Date: Sat, 31 Dec 2005 18:32:33 -0800

On 12/31/05, Tyler Durden 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. 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.

Alif the Terrible wrote...

(3) Since all off the pieces have been stored - including both the encrypted messagetexts and the decryptors, what is to prevent a time-faking attack against this message? After all, if you have all the parts, you can just "reinstantiate" the network as it was was the messages were originally sent.

Yes, agreed, but I think this a MUCH bigger pain in the ass. To wit: If they grab and deencrypt the "message" (ie the piece sent to the receiver) prior to the expiration time, then they will have the message and be able to read it. This is an improvement in that they have to do it prior to the expiration time of the hidden piece. They can not grab and store this piece alone because the other piece will not be there later. If they do not deencrypt the message in time, then they have to grab a core dump of the entire network (as well as the transmitted message), because they do not know where the piece is located. Seems to me that's a much harder thing to do then merely grabbing a sole message and de-encrypting it at their leisure. Seems to me too that a Tor network that was sufficiently dynamic could require network core dumps that could actually tax even NSA facilities, given large Tor networks of the future. It should also be pointed out that if the encryption on the "message" piece is done extremely carefully, one can afford to be lax on the Tor piece, and yet have a very difficult problem to crack (particularly if wrong guesses set off boobytraps that kill the hidden message piece). Again, it can be countered that an attack might merely require N instantiations of the network, but now we are talking some very significant resources. We've multiplied the originall cracking problem by N. Perhaps. -TD PS: I believe this is very close to having a one-time stored pad, but the difference with traditional Pads is that this one is tored in an anonymous location.(See Coderman's post.)

On 1/1/06, J.A. Terranson wrote:

(1) We are describing encryptedmessage sent over the public internet - granted, it's in "pieces", yet it's still sent into the public cloud;

yeah, follow tcp stream in ethereal is a good example of how trivial it is to recreate a session of communication given an archive of its component datagrams.

(2) These various pieces are all "record" communications as far as NSA/Echelon is concerned, and therefore we should expect that they will draw significant attention - and end up in permanent archives;

right. hence my fetish for one time pads for key exchange and previous comment about quantum computers / fast GNFS / etc. they are up to 8 qubits, only a few thousand more to go. ;)

(3) Since all off the pieces have been stored - including both the encrypted messagetexts and the decryptors, what is to prevent a time-faking attack against this message? After all, if you have all the parts, you can just "reinstantiate" the network as it was was the messages were originally sent.

this is particular to the method TD mentioned i think... i am assuming the following: - the operating system is installed on a loop-aes volume so that integrity of the kernel, libraries and utilities is protected via passphrase. - the one time pads are stored encrypted in a similar manner so that access to them requires external keys (like the gpg encrypted keys used for loop-aes volumes) - the passphrase used to authenticate a user for access to the pads is coupled with external storage (usb) of the keys used to access the pads. to recover the plaintext communication from the encrypted datagrams the attacker would need to obtain the encrypted pad, the keys on external storage (usb), and the passphrase to access the keys.

(4) For any form of time-destruction messaging to really work, the keying information would have to be tied to a physical <something> that cannot be reclaimed, and which decays at a fixed, known, and closely approximatable rate (a radiodecay probably doesn't meet this criteria);

Every time-sensitive auto-destructing system Ive seen discussed here fails these weaknesses.

this doesn't provide time destruction so i assume this is in reference to Tyler's description. you could couple the user authentication with a physically hardened token of some sort for access to the pads but even this would require manual destruction. do they make physically hardened authentication tokens with timed self destruction built in?

On 1/1/06, J.A. Terranson wrote:

... Is there radioactive material which has has a known property that can be reliably and repetitively measured, that is useful as either a key or a seed, and that is guaranteed to change on a known schedule in a significant (i.e., keying data no longer relevant) way?

The idea being something like msg xor radioseed "keys" = plaintext, but after 30 days, radioseed is different (and the original not knowable), and therefore message is dead.

it seems like this should be possible using a radioactive material with a known short half-life and exposing it to a neutron source with a mask (beryllium?) with the key space on it. assume a grid of cells on a flat surface containing the radioactive material; if a given cell emits over a threshold of radiation it is a '1' bit, dead it is a 0 bit. exposing the 0's to a neutron emitter would fission the radioactive cells early leaving it's ionizing radiation level below the threshold. there would be some delay between when the key was usable with all cells/bits readable (a few days, weeks, months?) and when it was still holding a detectable / useful amount of key information that could be used in a brute force attack against the unknown bits of key. they let you put americium in smoke detectors but something tells me it would be hard to get radioactive crypto keys commercially approved for production. :) (the neutron source would be another problem, although piezoelectric fusion might work)