[dave@farber.net: [IP] more on AP Story Justice Dept. Probing Domestic Spying Leak]
----- Forwarded message from David Farber <dave@farber.net> -----
Keep in mind that NSA has always gathered data on US citizens in the course of performing foreign intelligence but was heretofore supposed to filter rather than use it. What is different in the present case is that a decision was made to use the data, both newly gathered and likely that which was stored unfilered for future mining. What could come out of a DoJ probe is exactly who implemented that decision and whether they were given exculpation, and if so, how was that done and by whom. Did senior NSA officials get exculpation and if so what precisely was it and did it differ from what those lower down were given. Further, members of the military performing NSA duites are given different exculpation than the civilians due to differing employment and service regulations. A large percentage of interception operatives are civilians, some former service members but far from all. US civilian intelligence members -- State, FBI, DEA, and several other departments with intelligence duties -- are also involved in processing intercepted data and preparing it for distribution to NSA customers. And there are foreign military members working at NSA as well as civilians -- and those are not only from UK, CA, AU and NZ but from NATO and other treaty country participants. These foreign operatives are given instructions both by their own superiors and also by those from the US on how to handle intercepts of citizens from the countries who provide NSA operatives as well as data gathered on US citizens. There have been incidents reported of these foreign operatives performing or processing intercepts forbidden to the US while sitting adjacent to the US operatives, with consequent disclosure. This goes beyond the well-known US-UK backscratching. Beyond orders to gather information on US citizens there is the question of what was done to mine long-stored raw data which has presumably been filtered. Recall NSA policy to never discard any encrypted material gathered, none, forever. It is likely there is voluminous material on US citizens stored and ready for reassessment as needs be. There have been numerous revelations of other countries storing such data for decades, an example are the decades-long Stasi files obtained by the CIA from East Germany which the agency will still not release. All countries with intelligence capabilities have such files. And few are required to release them, such as the UK and US sometimes do for a small number. The US is surely not alone in amassing huge new files as a result of the terrorism intiative, for every time there is a war there is a surge in spying across the board, at home and overseas. 9/11 was a godsend to the spying industry which was slowly withering with the winddown of the artificially-prolonged Cold War. To be sure it has been immensely beneficial to the media industry, and a slew of other boats lifted by the desire for more information, the dirtier the better. Nice to see ACLU put its Echelon Watch files back up. A while back we went looking for Echelon Watch files at ACLU and found a bunch of them through Google still on the ACLU website, but nary a link on the main pages. Perhaps EPIC and others will also have a change of mind about Echelon after withdrawing material post-9/11. The there's Bamford's admission that after being invited to NSA for royal treatment and a classified briefing, he found the agency not so monstrous. What he was briefed on cannot be revealed, apparently, only that the place is honorably operated. When David Kahn was doing research at NSA, he claims he refused to be suckered and tainted by being given access to classified material. Big deceptions are often hidden by small ones delivered as exposes, and those given access to secrets are customarily obliged to tell only a sanitized version glossed with trust me the ex-trustworthy investigator.
John Young wrote...
Beyond orders to gather information on US citizens there is the question of what was done to mine long-stored raw data which has presumably been filtered. Recall NSA policy to never discard any encrypted material gathered, none, forever. It is likely there is voluminous material on US citizens stored and ready for reassessment as needs be.
There have been numerous revelations of other countries storing such data for decades,
Seems to me there should be a nice workaround for this, crypto-wise. Again, sorry if this is well-known. No time to keep up these days. BUT, encrypted messages should have something like an expiring one-off time stamp. It could work like this: Message is encrypted and broken into 2 or more pieces. Neither piece is sufficient to reconstruct the message. Piece one is sent as the "message" (or maybe the message is merely a pointer to the various encrypted pieces). Message 2 is stored somewhere in a Tor-based repository (ie, the actual address is unknown). The key includes encrypted instructions on where to obtain the other half as well as deencrypting the message. If the message is not de-encrypted with X days, the stored piece(s) is\are destroyed. Of course, NSA will likely grab&store the hidden piece as well, 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). -TD
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. 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.
At 6:32 PM -0800 12/31/05, coderman wrote:
a one time pad based IPsec key daemon
There ya go. Time for some *real* cryptography, dammit! ;-) Cheers, RAH -- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
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 <coderman@gmail.com> 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 Date: Sat, 31 Dec 2005 18:32:33 -0800
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. 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.
On Sun, 1 Jan 2006, Tyler Durden wrote: A couple of points trouble me here, to wit: (1) We are describing encryptedmessage sent over the public internet - granted, it's in "pieces", yet it's still sent into the public cloud; (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; (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. (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. -- Yours, J.A. Terranson sysadmin@mfn.org 0xBD4A95BF 'The right of self defence is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and the right of the people to keep and bear arms is, under any colour or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction.' St. George Tucker
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, Tyler Durden <camera_lumina@hotmail.com> wrote:
... 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.
this reminded me of 'cryptoogle' which seems easily compromised but operates using a time delayed expiration of key material as derived from search results: http://www.cryptoogle.com/encrypt.php
On 1/1/06, J.A. Terranson <measl@mfn.org> 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 Sun, 1 Jan 2006, coderman wrote:
(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?
Not that I am aware of, and if they did, I would by definition not trust them. I want my time-limited key to be some natural phenomenon that cannot be recreated after it "dies", but which is "readable" (for keying) and stable for a known time interval. 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. -- Yours, J.A. Terranson sysadmin@mfn.org 0xBD4A95BF 'The right of self defence is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and the right of the people to keep and bear arms is, under any colour or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction.' St. George Tucker
On 1/1/06, J.A. Terranson <measl@mfn.org> 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)
participants (6)
-
coderman -
Eugen Leitl -
J.A. Terranson -
John Young -
R. A. Hettinga -
Tyler Durden