Re: [Cryptography] check-summed keys in secret ciphers?
On Mon, Sep 30, 2013 at 7:44 PM, arxlight arxli...@arx.li wrote: Just to close the circle on this: The Iranians used hundreds of carpet weavers (mostly women) to reconstruct a good portion of the shredded documents which they published (and I think continue to publish) eventually reaching 77 volumes of printed material in a series wonderfully named Documents from the U.S. Espionage Den. They did a remarkably good job, considering: http://upload.wikimedia.org/wikipedia/commons/6/68/Espionage_den03_14.png There is a back story to that. One of the reasons that Ayatolah Kohmenhi knew about the CIA and embassy involvement in the 53 coup was that he was one of the hired thugs who raised the demonstrations that toppled Mossadegh. So the invasion of the embassy was in part motivated by a desire to burn any evidence of that perfidy on the regimes part. It was also used to obtain and likely forge evidence against opponents inside the regime. The files were used as a pretext for the murder of many of the leftists who were more moderate and western in their outlook. On the cipher checksum operation, the construction that would immediately occur to me would be the following: k1 = R(s) kv = k1 + E(k1, kd)// the visible key sent over the wire, kd is a device key This approach allows the device to verify that the key is intended for that device. A captured device cannot be used to decrypt arbitrary traffic even if the visible key is known. The attacker has to reverse engineer the device to make use of it, a task that is likely to take months if not years. NATO likely does an audit of every cryptographic device every few months and destroys the entire set if a single one ever goes missing. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] check-summed keys in secret ciphers?
Hi, Am 2013-09-30 10:16, schrieb ianG: I'm not really understanding the need for checksums on keys. Perhaps it is a DLP (Data Leakage Prevention) technology. At least the same method works great for Creditcard numbers. Oh, there is a 14 digit number being sent on a unclassified network, and all the checksums are correct? Someone is trying to leak ... terminate the connection, forensically analyze the machine, ... Best regards, Philipp ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] check-summed keys in secret ciphers?
On 29/09/13 16:01 PM, Jerry Leichter wrote: ...e.g., according to Wikipedia, BATON is a block cipher with a key length of 320 bits (160 of them checksum bits - I'd guess that this is an overt way for NSA to control who can use stolen equipment, as it will presumably refuse to operate at all with an invalid key). ... I'm not really understanding the need for checksums on keys. I can sort of see the battlefield requirement that comms equipment that is stolen can't then be utilized in either a direct sense (listening in) or re-sold to some other theater. But it still doesn't quite work. It seems antithetical to NSA's obsession with security at Suite A levels, if they are worried about the gear being snatched, they shouldn't have secret algorithms in them at all. Using checksums also doesn't make sense, as once the checksum algorithm is recovered, the protection is dead. I would have thought a HMAC approach would be better, but this then brings in the need for a centralised key distro approach. Ok, so that is typically how battlefield codes work -- one set for everyone -- but I would have thought they'd have moved on from the delivery SPOF by now. Cryptographic challenge: If you have a sealed, tamper-proof box that implements, say, BATON, you can easily have it refuse to work if the key presented doesn't checksum correctly. In fact, you'd likely have it destroy itself if presented with too many invalid keys. NSA has always been really big about using such sealed modules for their own algorithms. (The FIPS specs were clearly drafted by people who think in these terms. If you're looking at them while trying to get software certified, many of the provisions look very peculiar. OK, no one expects your software to be potted in epoxy (opaque in the ultraviolet - or was it infrared?); but they do expect various kinds of isolation that just affect the blocks on a picture of your software's implementation; they have no meaningful effect on security, which unlike hardware can't enforce any boundaries between the blocks.) Anyway, this approach obviously depends on the ability of the hardware to resist attacks. Can one design an algorithm which is inherently secure against such attacks? For example, can one design an algorithm that's strong when used with valid keys but either outright fails (e.g., produces indexes into something like S-boxes that are out of range) or is easily invertible if used with invalid keys (e.g., has a key schedule that with invalid keys produces all 0's after a certain small number of rounds)? You'd need something akin to asymmetric cryptography to prevent anyone from reverse-engineering the checksum algorithm from the encryption algorithm, but I know of no fundamental reason why that couldn't be done. It also seems a little overdone to do that in the algorithm. Why not implement a kill switch with a separate parallel system? If one is designing the hardware, then one has control over these things. I guess then I really don't understand the threat they are trying to address here. Any comments from the wider audience? iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] check-summed keys in secret ciphers?
On 9/30/13 at 1:16 AM, i...@iang.org (ianG) wrote: Any comments from the wider audience? I talked with a park ranger who had used a high-precision GPS system which decoded the selective availability encrypted signal. Access to the device was very tightly controlled and it had a control-meta-shift-whoopie which erased the key should the device be in danger of being captured. And this was a relatively low security device. Cheers - Bill --- Bill Frantz|After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.pwpconsult.com | wouldn't it? -- Marcus Ranum ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] check-summed keys in secret ciphers?
GOST was specified with S boxes that could be different for different applications, and you could choose s boxes to make GOST quite weak. So that's one example. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] check-summed keys in secret ciphers?
On Sep 30, 2013, at 4:16 AM, ianG i...@iang.org wrote: I'm not really understanding the need for checksums on keys. I can sort of see the battlefield requirement that comms equipment that is stolen can't then be utilized in either a direct sense (listening in) or re-sold to some other theater. I'm *guessing* that this is what checksums are for, but I don't actually *know*. (People used to wonder why NSA asked that DES keys be checksummed - the original IBM Lucifer algorithm used a full 64-bit key, while DES required parity bits on each byte. On the one hand, this decreased the key size from 64 to 56 bits; on the other, it turns out that under differential crypto attack, DES only provides about 56 bits of security anyway. NSA, based on what we saw in the Clipper chip, seems to like running crypto algorithms tight: Just as much effective security as the key size implies, exactly enough rounds to attain it, etc. So *maybe* that was why they asked for 56-bit keys. Or maybe they wanted to make brute force attacks easier for themselves.) But it still doesn't quite work. It seems antithetical to NSA's obsession with security at Suite A levels, if they are worried about the gear being snatched, they shouldn't have secret algorithms in them at all. This reminds me of the signature line someone used for years: A boat in a harbor is safe, but that's not what boats are for. In some cases you need to communicate securely with someone who's in harm's way, so any security device you give him is also in harm's way. This is hardly a new problem. Back in WW I, code books on ships had lead covers and anyone who had access to them had an obligation to see they were tossed overboard if the ship was about to fall into enemy hands. Attackers tried very hard to get to the code book before it could be tossed. Embassies need to be able to communicate at very high levels of security. They are normally considered quite secure, but quiet attacks against them do occur. (There are some interesting stories of such things in Peter Wright's Spycatcher, which tells the story of his career in MI5. If you haven't read it - get a copy right now.) And of course people always look at the seizure of the US embassy in Iran. I don't know if any crypto equipment was compromised, but it has been reported that the Iranians were able, by dint of a huge amount of manual labor, to piece back together shredded documents. (This lead to an upgrade of shredders not just by the State Department but in the market at large, which came to demand cross-cut shredders, which cut the paper into longitudinal strips, but then cut across the strips to produce pieces no more than an inch or so long. Those probably could be re-assembled using computerized techniques - originally developed to re-assemble old parchm ents like the Dead Sea Scrolls.) Today, there are multiple layers of protection. The equipment is designed to zero out any embedded keys if tampered with. (This is common even in the commercial market for things like ATM's.) A variety of techniques are used to make it hard to reverse-engineer the equipment. (In fact, even FIPS certification of hardware requires some of these measures.) At the extreme, operators of equipment are supposed to destroy it to prevent its capture. (There was a case a number of years back of a military plane that was forced by mechanical trouble to land in China. A big question was how much of the equipment had been destroyed. There are similar cases even today with ships, in which people on board take axes to the equipment.) Using checksums also doesn't make sense, as once the checksum algorithm is recovered, the protection is dead. The hardware is considered hard to break into, and one hopes it's usually destroyed. The military, and apparently the NSA, believes in defense in depth. If someone manages to get the checksum algorithm out, the probably have the crypto algorithm, too. I would have thought a HMAC approach would be better, but this then brings in the need for a centralised key distro approach. Why HMAC? If you mean a keyed MAC ... it's not better. But a true signature would mean that even completely breaking a captured device doesn't help you generate valid keys. (Of course, you can modify the device - or a cloned copy - to skip the key signature check - hence my question as to whether one could create a crypto system that *inherently* had the properties that signed keys naively provide.) Ok, so that is typically how battlefield codes work -- one set for everyone -- but I would have thought they'd have moved on from the delivery SPOF by now. In a hierarchical organization, centralized means of control are considered important. There was an analysis of the (bad) cryptography in secure radios for police and fire departments, and it mainly relied on distribution of keys from a central source. ...It also seems a
Re: [Cryptography] check-summed keys in secret ciphers?
On 9/30/13 11:07 PM, Jerry Leichter wrote: On Sep 30, 2013, at 4:16 AM, ianG i...@iang.org wrote: But it still doesn't quite work. It seems antithetical to NSA's obsession with security at Suite A levels, if they are worried about the gear being snatched, they shouldn't have secret algorithms in them at all. This reminds me of the signature line someone used for years: A boat in a harbor is safe, but that's not what boats are for. In some cases you need to communicate securely with someone who's in harm's way, so any security device you give him is also in harm's way. This is hardly a new problem. Back in WW I, code books on ships had lead covers and anyone who had access to them had an obligation to see they were tossed overboard if the ship was about to fall into enemy hands. Attackers tried very hard to get to the code book before it could be tossed. Embassies need to be able to communicate at very high levels of security. They are normally considered quite secure, but quiet attacks against them do occur. (There are some interesting stories of such things in Peter Wright's Spycatcher, which tells the story of his career in MI5. If you haven't read it - get a copy right now.) And of course people always look at the seizure of the US embassy in Iran. I don't know if any crypto equipment was compromised, but it has been reported that the Iranians were able, by dint of a huge amount of manual labor, to piece back together shredded documents. (This lead to an upgrade of shredders not just by the State Department but in the market at large, which came to demand cross-cut shredders, which cut the paper into longitudinal strips, but then cut across the strips to produce pieces no more than an inch or so long. Those probably could be re-assembled using computerized techniques - originally developed to re-assemble old parc hm ents like the Dead Sea Scrolls.) Just to close the circle on this: The Iranians used hundreds of carpet weavers (mostly women) to reconstruct a good portion of the shredded documents which they published (and I think continue to publish) eventually reaching 77 volumes of printed material in a series wonderfully named Documents from the U.S. Espionage Den. They did a remarkably good job, considering: http://upload.wikimedia.org/wikipedia/commons/6/68/Espionage_den03_14.png You can see a bunch of the covers via Google Books here: http://books.google.com/books?q=editions:LCCN84193484 You could peruse the entire collection in a private (but not secret) library of which I was once a member (outside the United States of course) and I seem to remember that a London library had a good number of the books too, despite the fact that the material was still classified at the time (and I think still is?) Perhaps it would be amusing to write to the old publisher and see if one can still order the entire set: Center for the Publication of the U.S. Espionage Den's Documents P.O. Box 15815-3489 Teheran Islamic Republic of Iran Then again, you might find yourself unable to get on international flights for a time after such a request, who knows. On your speculation about crosscut shredding, you're right on the money. DARPA ran a de-shredding challenge in 2011. A team from San Fran (All Your Shreds Are Belong To U.S.) won by substantially reconstructing 5 of 7 puzzles. DARPA has since yanked the content there (or it has merely succumbed to bitrot/linkrot) but I recall it being impressive. The amount reconstructed from very high security cross-shred was eye-opening. Ah, found a mirror (on a site selling shredding services, of course): http://www.datastorageinc.com/blog/?Tag=shredding Lesson 1: Don't use line-ruled paper. Ever. Lesson 2: Burn or pulp after you shred. One imagines that substantial progress on the problem has been made since the contest. Ah, I see in writing this that there's a Wikipedia article on it too: http://en.wikipedia.org/wiki/DARPA_Shredder_Challenge_2011 Which, in turn, lists the DARPA archive: http://archive.darpa.mil/shredderchallenge/ As you might imagine, the events of 1979 caused quite a stir when it came to the security of Department of State facilities. What might surprise you, however, would be to learn that most of this work was done on improving time to destruction of classified material, and the means to buy that time (read: Marines) for duty officers (read: intelligence officers), and not actually improving security for diplomatic staff. Those jarheads aren't for you folks, they are for the Classified. -uni ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] check-summed keys in secret ciphers?
On 9/30/13 at 2:07 PM, leich...@lrw.com (Jerry Leichter) wrote: People used to wonder why NSA asked that DES keys be checksummed - the original IBM Lucifer algorithm used a full 64-bit key, while DES required parity bits on each byte. On the one hand, this decreased the key size from 64 to 56 bits; on the other, it turns out that under differential crypto attack, DES only provides about 56 bits of security anyway. NSA, based on what we saw in the Clipper chip, seems to like running crypto algorithms tight: Just as much effective security as the key size implies, exactly enough rounds to attain it, etc. So *maybe* that was why they asked for 56-bit keys. Or maybe they wanted to make brute force attacks easier for themselves. The effect of NSA's work with Lucifer to produce DES was: DES was protected against differential cryptanalysis without making this attack public. The key was shortened from 64 bits to 56 bits adding parity bits. I think the security side of NSA won here. It is relatively easy to judge how much work a brute force attack will take. It is harder to analyze the effect of an unknown attack mode. DES users could make a informed judgment based on $$$, Moore's law, and the speed of DES. Cheers - Bill --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
