Re: Field slide attacks and how to avoid them.
But XDR is so BORING compared to a REAL standard like ASN.1! It doesn't have infinite possibilies for object definitions requiring help from standards committees, multiple incompatible data representations with different kinds of ambiguity, or ugly API packages that are too large to believe that the implementers debugged them adequately. That's just no fun at all! (I realize it doesn't do everything in the world, or have all the power, expressiveness, or bit-twiddling that ASN.1 or even PGP/OpenPGP data formats have, but there's a lot to be said for something that's minimal and works.) At 04:50 PM 09/10/2001 -0400, Kevin E. Fu wrote: We use hashes of marshalled XDR representations of data in the SFS read-only file system [2]. This allows us to protect the integrity of public, read-only content without having to worry about simple splicing attacks. The eXternal Data Representation Standard is popular for implementing things like NFS [2, 4]. ... [0] 6.033 Spring 2001 Quiz 2. http://web.mit.edu/6.033/www/handouts/s01_2.ps [1] Dos and Dont's of Client Authentication on the Web, USENIX Security 2001, http://cookies.lcs.mit.edu/ [2] NFS Version 3 Protocol Specification, RFC 1813 [3] SFS Read-only File System, USENIX OSDI 2000, http://www.fs.net/ [4] XDR: External Data Representation, RFC 1014 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
Kevin E. Fu [EMAIL PROTECTED] writes: But XDR is so BORING compared to a REAL standard like ASN.1! It doesn't have infinite possibilies for object definitions requiring help from standards committees, multiple incompatible data representations with different kinds of ambiguity, or ugly API packages that are too large to believe that the implementers debugged them adequately. That's just no fun at all! I can feel this sliding into a specification language debate, but I have to put in a word to defend ASN.1 here. When used by a skilled practitioner, ASN.1 can be truly elegant. The problem is that, like BASIC, it looks deceptively simple, so that everyone thinks they can write a spec in ASN.1 after five minutes study of an ASN.1 introductory guide, and they usually do. The result is a great confused muddle which noone can figure out and everyone implements slightly differently, leading to ASN.1's reputation of being a pain to work with (to paraphrase the famous FORTRAN comment, The determined hack can write crap in any language). Having had experience working with ASN.1, XDR, the SSL specification notation, and PGP, I definitely prefer ASN.1 for its ability (when used correctly) to provide a clear, unambiguous definition of a data exchange format. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
At 03:55 20/09/2001, Peter Gutmann wrote: Paul Crowley [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Peter Gutmann) writes: Kevin E. Fu [EMAIL PROTECTED] writes: But XDR is so BORING compared to a REAL standard like ASN.1! I can feel this sliding into a specification language debate, but I have to put in a word to defend ASN.1 here. Those choosing data formats for crypto purposes might want to consider the simple and elegant format S-expression used by SPKI, described here: And those who enjoy pain shouldn't forget X.12, EDIFACT, and HL7. Surely we should all be using some sort of *XML* format! ;-) J - James Robertson Step Two Designs Pty Ltd Knowledge Management Consultancy, SGML XML Illumination: an out-of-the-box Intranet solution http://www.steptwo.com.au/ [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
Or also their XML equivalents: http://xml.coverpages.org/xml-spki.html Enzo - Original Message - From: Paul Crowley [EMAIL PROTECTED] To: Peter Gutmann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, September 20, 2001 1:49 AM Subject: Re: Field slide attacks and how to avoid them. [EMAIL PROTECTED] (Peter Gutmann) writes: Kevin E. Fu [EMAIL PROTECTED] writes: But XDR is so BORING compared to a REAL standard like ASN.1! I can feel this sliding into a specification language debate, but I have to put in a word to defend ASN.1 here. Those choosing data formats for crypto purposes might want to consider the simple and elegant format S-expression used by SPKI, described here: http://theory.lcs.mit.edu/~rivest/sexp.txt [Moderator's note: I'm a big fan of that format. --Perry] -- __ Paul Crowley \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/ Conservation of angular momentum makes the world go around - John Clark - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
The problem is that an ambiguous message is signed, making this attack possible: (username, expiration) - MAC signature - -- (Alice, 21-Apr-2001- MAC (Alice21-Apr-2001, key) (Alice2, 1-Apr-2001- MAC (Alice21-Apr-2001, key) An adversary need only create an Alice2 account with an appropriate expiration time to forge an authenticator for the real Alice. In the real world, sites and systems like WSJ.com and ArsDigita ACS suffer from variants of this marshalling problem [1]. Just sign what you mean -- using a delimiter or variable name outside the message space is usually sufficient. so change that to (username, expiration) - MAC signature - -- (Alice, 21-Apr-2001- MAC (MAC(Alice), MAC(21-Apr-2001), key) (Alice2, 1-Apr-2001- MAC (MAC(Alice2), MAC(1-Apr-2001), key) maybe? -- |- CODE WARRIOR -| [EMAIL PROTECTED] * ah! i see you have the internet [EMAIL PROTECTED] (Andrew Brown)that goes *ping*! [EMAIL PROTECTED] * information is power -- share the wealth. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
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.) ... This is the kind of thing that someone must have already dealt with in detail. Any references? Are any of these ideas useful? There is nothing very difficult about any of them, and it would be trivial to come up with dozens of similar fixes. We use hashes of marshalled XDR representations of data in the SFS read-only file system [2]. This allows us to protect the integrity of public, read-only content without having to worry about simple splicing attacks. The eXternal Data Representation Standard is popular for implementing things like NFS [2, 4]. Recently I've spent quite a bit of time analyzing cookie-based, HTML-form-based, and URL-based authenticators. As you might expect, many of these systems fall to the basic attack you describe. One of my favorite bad schemes is from an operating sytems class at MIT [0] (no offense to my thesis advisor...): auth = expiration time + MAC_k(expiration time) The problem is that an ambiguous message is signed, making this attack possible: (username, expiration) - MAC signature - -- (Alice, 21-Apr-2001- MAC (Alice21-Apr-2001, key) (Alice2, 1-Apr-2001- MAC (Alice21-Apr-2001, key) An adversary need only create an Alice2 account with an appropriate expiration time to forge an authenticator for the real Alice. In the real world, sites and systems like WSJ.com and ArsDigita ACS suffer from variants of this marshalling problem [1]. Just sign what you mean -- using a delimiter or variable name outside the message space is usually sufficient. -Kevin Fu [0] 6.033 Spring 2001 Quiz 2. http://web.mit.edu/6.033/www/handouts/s01_2.ps [1] Dos and Dont's of Client Authentication on the Web, USENIX Security 2001, http://cookies.lcs.mit.edu/ [2] NFS Version 3 Protocol Specification, RFC 1813 [3] SFS Read-only File System, USENIX OSDI 2000, http://www.fs.net/ [4] XDR: External Data Representation, RFC 1014 Kevin E. Fu ([EMAIL PROTECTED]) PGP key: https://snafu.fooworld.org/~fubob/pgp.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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]
