Jakob Bohm <jb-mozi...@wisemo.com> writes: >Surprised you didn't know that, considering who you are.
Uhh, I did know that, that's why I checked it about 15-odd years ago to see if anything would notice if it was done wrong (I can't remember the exact date, it was when I was still updating the X.509 Style Guide so around 1999 or 2000). At the time, it was OK with DLP sigs as well since the only thing that was allowed was DSA + SHA-1, and obviously PKCS #1 was fine too, it was 9796-2 certs that had problems, but then they were barely used by anyone except some European banks. Now, we have ECDSA, which not only has this problem in spades but even has a requirement (X9.62) to truncate the hash to fit the group order. So you can swap in any hash you want (that's specified for use with ECDSA) and standards- compliant code will helpfully adjust it for you to make sure the attack works. Certs protect against this (assuming the code checks the signature vs. signatureAlgorithm), but generalised signing doesn't, e.g. with both PGP and CMS / S/MIME the hash function identifier isn't an authenticated attribute. This is why CMS authenticated-enveloped-data MACs the EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier, so you can't manipulate the algorithm parameters: The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier must be protected alongside the encrypted content; otherwise, an attacker could manipulate the encrypted data indirectly by manipulating the encryption algorithm parameters, which wouldn't be detected through MACing the encrypted content alone. For example, by changing the encryption IV, it's possible to modify the results of the decryption after the encrypted data has been verified via a MAC check. The test vectors then say: For the triple DES-encrypted data, corrupting a byte at positions 192-208 can be used to check that payload-data corruption is detected, and corrupting a byte at positions 168-174 can be used to check that metadata corruption is detected. to make sure that the code to check for problems is working as required. Peter. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
