Re: Field slide attacks and how to avoid them.
John Kelsey wrote: -BEGIN PGP SIGNED MESSAGE- [ To: Perry's Crypto List ## Date: 09/08/01 07:35 pm ## Subject: Field slide attacks and how to avoid them. ] Guys, I've been noticing a lot of ways you can mess up a cryptographic protocol due to the sliding around of fields within a signed or MACed message. The classic example of this is the old attack on PGP fingerprints, which let you use some odd keysize, and thus get two different keys (with different keysizes) with the same hash, without breaking the hash function. (The raw bits of the two keys are the same, but the fields are broken up differently.) The natural way to resist this is to ensure that all information used to parse a hashed/MACed/signed message is included in the signature. But I was curious whether anyone knows of other standard, simple ways to deal with this problem? ASN.1/DER. Note that I am not advocating it, merely pointing out that it a standard (if not entirely simple) way to deal with the problem. d. Encode the fields first, in such a way that there is a single unambigous field separator between fields. For example, use the simple encoding rule that anytime three bytes of successive 0x00s are encoded, we always insert a 0x01 byte next. Use four successive 0x00 bytes as the field separator. The decoding rules work just the opposite: Whenever we run into 0x00,0x00,0x00, if the next byte is 0x00, we've hit a field separator; if it's a 0x01, we discard the 0x01 and continue decoding. Its more efficient to insert the 0x01 (in the 4th position) only if there is a run of 4 0x00, or 0x00,0x00,0x00,0x01. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Compression side channel
On Sat, Sep 08, 2001 at 10:45:14PM -0400, John Kelsey wrote: where the encryption preserves length (e.g., RC4 encryption). Suppose someone is sending a secret S in these messages, and the attacker gets to choose some prefix or suffix to send, e.g. X[0] = S+suffix[0] X[1] = S+suffix[1] ... Good point. The mistake seems to be mixing a (non-compressible) secret and a (compressible, possibly attacker-chosen) message in one compression run. It seems to be a good idea to compress every logical part of the plaintext separately (and to compress only things which are compressible). Hadmut - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sen. Hollings plans to introduce DMCA sequel: The SSSCA
On Sun, 9 Sep 2001, Carsten Kuckuk wrote: Am I right in that this bill would effectively outlaw all free open-source operating systems like Linux, OpenBSD, FreeBSD, etc.? Carsten Kuckuk Yes. All interactive digital systems that directly connect to the net will have to licensed. Most that do not connect directly will also have to be licensed. License costs will be high enough so that only a few large companies can afford them. Individuals will not be allowed to assemble components to make a computer for themselves, unless they spend millions on a license, and wait some months for the paperwork to go through. oo--JS. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
SSSCA = Digital Rectal Thermometer Security Act ?
Hi all -- I just sat down and read the proposed text of the Holling's SSSCA bill. http://cryptome.org/sssca.htm Boy is this bill breathtaking in its breadth! I have tried to understand its language. It says in Section 101: It is unlawful to manufacture, import, offer to the public, provide or otherwise traffic in any interactive digital device that does not include and utilize certified security technologies that adhere to the security systems standards adopted under section 104. and says in Section 109: The term interactive digital device means any machine, device, product, software, or technology, whether or not included with or as part of some other machine, device, product, software, or technology, that is designed, marketed or used for the primary purpose of, and that is capable of, storing, retrieving, processing, performing, transmitting, receiving, or copying information in digital form. Putting 2+2 together, we see that essentially all digital devices and software will have to have certified security technologies in them. Anything that works primarily with digital data is covered. My feeble brain came up with the following list of things that would have to be secured. I'm sure you can think of lots more. -- All bar-code scanners -- All computer-controlled ignition systems -- All metro ticket readers -- All digital watches and calculators -- All ATM machines -- All digital cellular phones -- All digital answering machines -- All GPS receivers -- All sports scoreboards and the marquee signs in Times Square -- All electronic parking meters -- Almost all lab equipment (everything is digital these days) -- All software, for sure -- All digital cameras and digital movie cameras -- All PC's and game consoles -- All remote key-entry systems and most home security systems -- All stop-light controllers Well, I should leave some of the fun to you. But of course my favorite should be listed: -- All digital rectal thermometers Presumably some staffers will try to rescue this laughable (albeit a bit scary) lobbyist-written proposal. Of course, just letting the bill die is probably best. But if they want to fix things, they should consider adding language that makes it ILLEGAL to sell copy-protection technology that doesn't permit at least -- fair use, including time-shifting and making a reasonable number of copies for personal or educational use, or for backups, -- free use of a copyrighted item once the copyright has expired (This list should be expanded.) But in any case, making any security technology *mandatory* on all digital devices and computers is clearly a non-starter. Why, we'd probably have to close down all the country's computer science departments (can't have these kids making unsecured devices, you know, even if it is their homework assignment to build a computer...) Cheers, Ron Rivest Ronald L. Rivest Room 324, 200 Technology Square, Cambridge MA 02139 Tel 617-253-5880, Fax 617-258-9738, Email [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sen. Hollings plans to introduce DMCA sequel: The SSSCA
-- On 10 Sep 2001, at 0:26, Jay Sulzberger wrote: All interactive digital systems that directly connect to the net will have to licensed. Most that do not connect directly will also have to be licensed. License costs will be high enough so that only a few large companies can afford them. Individuals will not be allowed to assemble components to make a computer for themselves, unless they spend millions on a license, and wait some months for the paperwork to go through. When the chinese invented paper, the government eventually decided that this led to dangerous communication of dangerous thoughts, and prohibited private production of paper. It made paper making a state secret, and castrated all paper makers so that the secret would not be passed from father to son, but only transmitted in government approved channels. Thereafter paper was used only to transmit government approved thoughts through government channels, and to the populace. Computers are similarly dangerous. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG pEyJYvluyMSWgNZ7GAkKeNzQ3mshy+SsKVJ/wMhs 4sKLUftGKcn9X/CXUOs7SZPnTiZHI8M0IpiNhuyx6 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Compression side channel
Peter Wayner wrote: b. I'm hoping to find out if anyone else has seen similar work anywhere. I've not been able to find any references to this kind of attack, though once you've had the idea to try it, it's really pretty straightforward. (And I know there are a couple of occasional posters on this list who know a heck of a lot more about compression algorithms than I do. Peter, are you listening?) These are all good ideas, but I don't know how often you'll get to try them, much less use them enough to extract enough information. I wrote a paper a long time ago that tweaked compression algorithms. It wasn't meant to be secure, only ensure that the compression algorithms constantly changed the set of bits assigned to each character. This meant that a Huffman algorithm encoding 'e' as '0010' at one point would use '1011' later. It was a simple remapping of the compression tree so it wouldn't cost much. But I don't think it had any security on its own. It also wouldn't help at all in this context, since all that is used is the length, not the bits (which, inherently, you don't know anyway). Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
