Re: A note on vendor reaction speed to the e=3 problem
From a security point of view, shar has obvious problems :-) Really, what? There are things it doesn't do, but since it's only a packaging format that's a good thing. /r$ -- STSM, Senior Security Architect SOA Appliances Application Integration Middleware - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 9/26/06, Richard Salz [EMAIL PROTECTED] wrote: Really, what? There are things it doesn't do, but since it's only a packaging format that's a good thing. Though there are unshar tools, typically people run it as input to /bin/sh, usually without reading through it (and given the level of obfuscation sh offers, it's not clear that you couldn't sneak something through even if the person skims it). -- Enhance your calm, brother; it's just ones and zeroes. Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
| *That* is the Right Way To Do It. If there are variable parts (like | hash OID, perhaps), parse them out, then regenerate the signature data | and compare it byte-for-byte with the decrypted signature. | | You know, this sort of reminds me of a problem with signatures on | tar.gz files. Basically, you have to keep them around so you can | check the signature, but you can't delete them because you can't | reconstruct the original tar file from an untarred copy because it's | full of metadata that won't necessarily be replicated on your system. | For example, uids and gids. Unfortunately, cpio appears to be worse. | From a tape backup standpoint, tar doesn't store enough (extended | attributes, hard links, etc.) and so it appears to store both too much | and too little at once. VMS has for years had a simple CHECKSUM command, which had a variant, CHECKSUM/IMAGE, applicable only to executable image files. It knew enough about the syntax of executables to skip over irrelevant metadata like link date and time. (The checksums computed weren't cryptographic - at least the last time I used it, many years ago. The command was created to use in patches to provide a quick verification that the file being patched was the right one.) I've always found it surprising that no one seems to have developed similar tools for Unix - with the Gnu libraries for portable access to object/ executable files, it could be done relatively easily. The general issue here is how to checksum the information, rather than the raw data. XML signatures have horrendous problems with this because XML has many equivalent ways to say the same thing, and there is enough information in an XML file for intermediate nodes to be able to change representation without changing semantics - and for various reasons, they do so. (The XML guys try to deal with this by defining a canonical representation for data, and sign *that*. Unfortunately, there are two competing standards for the canonical representation.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
At 14:33 -0400 2006/09/28, Leichter, Jerry wrote: | VMS has for years had a simple CHECKSUM command, which had a variant, CHECKSUM/IMAGE, applicable only to executable image files. It knew enough about the syntax of executables to skip over irrelevant metadata like link date and time. (The checksums computed weren't cryptographic - at least the last time I used it, many years ago. The command was created to use in patches to provide a quick verification that the file being patched was the right one.) I've always found it surprising that no one seems to have developed similar tools for Unix - with the Gnu libraries for portable access to object/ executable files, it could be done relatively easily. The sum command has existed in Unixes since before VMS existed. Checksum has too many characters in the name ;-). Greg. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 2006-09-28, Leichter, Jerry wrote: VMS has for years had a simple CHECKSUM command, which had a variant, CHECKSUM/IMAGE, applicable only to executable image files. It knew enough about the syntax of executables to skip over irrelevant metadata like link date and time. (The checksums computed weren't cryptographic - at least the last time I used it, many years ago. The command was created to use in patches to provide a quick verification that the file being patched was the right one.) I've always found it surprising that no one seems to have developed similar tools for Unix - with the Gnu libraries for portable access to object/ executable files, it could be done relatively easily. This is incorrect. Hundreds of people have developed such tools and use them regularly. I've never bothered to look for any published versions, because my own tool works for me, but I'd be surprised if there weren't any out there in the wild. Greg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 9/15/06, Taral [EMAIL PROTECTED] wrote: *That* is the Right Way To Do It. If there are variable parts (like hash OID, perhaps), parse them out, then regenerate the signature data and compare it byte-for-byte with the decrypted signature. You know, this sort of reminds me of a problem with signatures on tar.gz files. Basically, you have to keep them around so you can check the signature, but you can't delete them because you can't reconstruct the original tar file from an untarred copy because it's full of metadata that won't necessarily be replicated on your system. For example, uids and gids. Unfortunately, cpio appears to be worse. From a tape backup standpoint, tar doesn't store enough (extended attributes, hard links, etc.) and so it appears to store both too much and too little at once. It would be nice if there was a format other than shar which was deterministic and only contained the contents of the files; no metadata. Then we could sign the code and nothing else. From a security point of view, shar has obvious problems :-) Anyone know of a relevant tool? -- Enhance your calm, brother; it's just ones and zeroes. Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: A note on vendor reaction speed to the e=3 problem
Anyway, the attack applies even if you throw away the ASN.1 data. If you ignore the ASN.1 data you expect the hash to be in a fixed byte position, so the attack does not apply. It's correct that the attack doesn't apply if you expect the hash to be in a fixed byte position. I would say that it's incorrect that there was no chance of it being screwed up in the absence of ASN.1. But I'm happy to agree to disagree at this point. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On Fri, Sep 15, 2006 at 09:48:16AM -0400, David Shaw wrote: GPG was not vulnerable, so no fix was issued. Incidentally, GPG does not attempt to parse the PKCS/ASN.1 data at all. Instead, it generates a new structure during signature verification and compares it to the original. Botan does the same thing for (deterministic) encodings - mostly because I wrote a decoder for PKCS#1 v1.5, realized it probably had bugs I wouldn't figure out until too late, and this way the worst thing that can happen is a valid signature is rejected due to having some unexpected but legal encoding. Default deny and all that. Anyway, it's a lot easier to write that way - my PSS verification code is probably around twice the length of the PSS generation code, due to the need to check every stupid little thing. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
Taral wrote: *That* is the Right Way To Do It. If there are variable parts (like hash OID, perhaps), parse them out, then regenerate the signature data and compare it byte-for-byte with the decrypted signature. Anything you don't understand/control that might be variable (e.g. options) is eliminated by this process. FSTC originally created FSML for digitally signed xml encoded data ... which was then donated to w3c and became part of xml digital signature specification. the issue for FSTC was e-checks ... where originator took fields from ACH transaction ... encoding them in XML, digitally signed the XML encoding, and then appended the signature to the original ACH transaction. the recipient received the ACH transaction ... duplicated the original XML encoding process, computed the hash ... and then compared it to the decoded signature (from the ACH transaction append field). the original issue for FSML was that XML didn't have a bit-deterministic encoding process ... which could result in the originator and the recipient getting different results doing XML encoding of ACH transaction fields. X9.59 financial transaction specified something similar http://www.garlic.com/~lynn/x9.59.html#x959 which allowed originator and recipient to perform deterministic encoding of standard financial transaction (in manner similar to FSTC e-check process) ... where the signature was carried in standard electronic transaction append field. the base standard specified ASN.1 encoding ... but the fully constituted x9.59 fields included a version field ... the purpose of which included being able to specify an x9.59 version that used XML encoding (rather than ASN.1 encoding). the standard just specified all the fields and ordering for the encoding. there were sample mappings between the fields in the standard and fields in various existing financial transactions. if x9.59 called for fields that weren't part of specific financial transaction ... then those fields needed to be carried in the transaction append/addenda, along with the digital signature (i.e. the digital signature was appended to standard transaction in unencoded format, it wasn't required that the encoded format being transmitted ... just that the encoded format could be reproduced in a deterministic manner). old write-up giving correspondence between x9.59 fields and some fields from some common financial transaction formats (includes a proposed xml tagged encoding) http://www.garlic.com/~lynn/8583flow.htm part of the issue for the x9.59 specification was the requirement for a standard that preserved the integrity of the financial infrastructure for all retail payments (ALL, including point-of-sale). A typical point-of-sale payment card transaction avgs. 60-80 bytes. By comparison, some of the PKI digital signature based specifications from the period had enormous payload bloat resulting in 4k-12k bytes ... aka increasing transaction payload size by two orders of magnitude (100 times). http://www.garlic.com/~lynn/subpubkey.html#x959 http://www.garlic.com/~lynn/subpubkey.html#certless - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
This amounts to *not* using ASN.1 - treating the ASN.1 data as mere arbitrary padding bits, devoid of information content. That is correct, it has the advantage of being merely a byte string that denotes a given hash. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On Sat, Sep 16, 2006 at 12:35:08PM +1000, James A. Donald wrote: -- Peter Gutmann wrote: How does [GPG] handle the NULL vs.optional parameters ambiguity? David Shaw: GPG generates a new structure for each comparison, so just doesn't include any extra parameters on it. Any optional parameters on a signature would cause that signature to fail validation. RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. This amounts to *not* using ASN.1 - treating the ASN.1 data as mere arbitrary padding bits, devoid of information content. That is correct. OpenPGP passes the hash identification in the OpenPGP data as well as encoded in ASN.1 for the PKCS-1 structure. Since there is another source for the information, it is unnecessary to generate or parse ASN.1. In the case of GPG specifically (other implementations may do the same, but I can't say for sure), all ASN.1 data is hardcoded opaque strings. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: A note on vendor reaction speed to the e=3 problem
RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. This amounts to *not* using ASN.1 - treating the ASN.1 data as mere arbitrary padding bits, devoid of information content. Again, not quite right. You have to do a memcmp() and make sure you've got the right arbitrary padding bits. Anyway, the attack applies even if you throw away the ASN.1 data. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
-- On 9/15/06, David Shaw [EMAIL PROTECTED] wrote: GPG was not vulnerable, so no fix was issued. Incidentally, GPG does not attempt to parse the PKCS/ASN.1 data at all. Instead, it generates a new structure during signature verification and compares it to the original. Taral wrote: *That* is the Right Way To Do It. If there are variable parts (like hash OID, perhaps), parse them out, then regenerate the signature data and compare it byte-for-byte with the decrypted signature. Anything you don't understand/control that might be variable (e.g. options) is eliminated by this process. I don't think there's anything inherently wrong with ASN.1 DER in crypto applications. If there are no options, you are not using ASN.1 DER. You are using some random padding bytes that happen to be equal to ASN.1 DER. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG mMZpx7gaL6S/5STlYWv0A0ZM+HqCZSD2m0ClWjxL 4UR16e+x3Uv/VW8C0Swxx9XMPtH99PEBNIc6BzpkQ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
-- Whyte, William wrote: Anyway, the attack applies even if you throw away the ASN.1 data. If you ignore the ASN.1 data you expect the hash to be in a fixed byte position, so the attack does not apply. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG qF2+GCfNPchHe4vzSkkYoOEjOI5i/kZtLIlyTUbX 45tXJAuT/Tj9w0qpg0VFij8GrtY2JXG05fj6YE6M2 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
David Shaw [EMAIL PROTECTED] writes: RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. Ah, OK, and it uses the NULL-parameters interpretation (section 5.2.2), which would actually be incorrect according to the current standards but at least it's unambiguous. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
-- Peter Gutmann wrote: How does [GPG] handle the NULL vs.optional parameters ambiguity? David Shaw: GPG generates a new structure for each comparison, so just doesn't include any extra parameters on it. Any optional parameters on a signature would cause that signature to fail validation. RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. This amounts to *not* using ASN.1 - treating the ASN.1 data as mere arbitrary padding bits, devoid of information content. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG KBZXRF1divvJGZ6Zm3lHv3qjnS9Bwhl22NfSlYK3 4zPRSIE0Q6qUaTtmKPPoKOsPNzAtcdWuthGi5nNTi - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
A note on vendor reaction speed to the e=3 problem
When I fired up Firefox a few minutes ago it told me that there was a new update available to fix security problems. I thought, Hmm, I wonder what that would be It's interesting to note that we now have fixes for many of the OSS crypto apps (OpenSSL, gpg, Firefox (via NSS, so probably Thunderbird as well), my own cryptlib), but nothing from any of the commercial vendors. Maybe someone should convert this into a DRM attack so Microsoft will fix it before 2007 :-). (The real #*($#*( for me is that I wanted to turn off e=3 years ago, but when I did it in a snapshot release some squawk piped up to say that they were using e=3 and the standard said it was OK and I was being non-standards compliant and so on and so forth, so in the end I had to leave it enabled. I did make it very easy to turn off with a single-character code change, but that may explain why commercial vendors are going to be reluctant to rush out a fix without a lot of prior impact assessment). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On Fri, Sep 15, 2006 at 08:49:31PM +1200, Peter Gutmann wrote: When I fired up Firefox a few minutes ago it told me that there was a new update available to fix security problems. I thought, Hmm, I wonder what that would be It's interesting to note that we now have fixes for many of the OSS crypto apps (OpenSSL, gpg, Firefox GPG was not vulnerable, so no fix was issued. Incidentally, GPG does not attempt to parse the PKCS/ASN.1 data at all. Instead, it generates a new structure during signature verification and compares it to the original. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
David Shaw [EMAIL PROTECTED] writes: Incidentally, GPG does not attempt to parse the PKCS/ASN.1 data at all. Instead, it generates a new structure during signature verification and compares it to the original. How does it handle the NULL vs.optional parameters ambiguity? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On Sat, Sep 16, 2006 at 05:35:27AM +1200, Peter Gutmann wrote: David Shaw [EMAIL PROTECTED] writes: Incidentally, GPG does not attempt to parse the PKCS/ASN.1 data at all. Instead, it generates a new structure during signature verification and compares it to the original. How does it handle the NULL vs.optional parameters ambiguity? GPG generates a new structure for each comparison, so just doesn't include any extra parameters on it. Any optional parameters on a signature would cause that signature to fail validation. RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
