Re: Another place to put garbage for collisions

Hi Brad, Thomas and others

Brad Hill wrote:
> Is it worth doing anything about (1), given (2)?
>   

I don't think we have to do anything here, ... (see further down)

... however another form of garbage should be removed in XMLDSig 1.1 ...
... insignificant whitespace in the ds:SignedInfo to make signatures
robust against re-indention.
http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#nameddest=subsection.4.1.3

Whitespace removal from the ds:SignedInfo can not be performed in
XMLDSig at the moment.
http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#nameddest=subsection.4.2.1

> [...] inherently have an additional layer of indirection (signing a hash of a hash) there's no way to avoid this type of collision attack.
>   
I'm not aware of anything other than "normal" collisions, ...

> [...] somewhat easier by the ability to embed arbitrary namespace declarations, and especially comments (if Bob accepts withComments as a C14N method SignedInfo).

The ds:SignedInfo and ds:Manifest form hash trees that are "interleaved"
with markup, the freedom in the markup potentially gives places to add
redundancy to find "meaningful" collisions, but any unconstrained value
of any attribute could do the same, ID, URI etc. ... even all the hash
values can arbitrarily be changed as they are not constrained beside
their length.

This is no problem however and will always cause the ds:SignatureValue
(i.e. the hash in the signature scheme) to change and the signature will
fail, iff you use a collision/preimage/2nd-preimage resistant hash
function.  (e.g. SHA-256 or above, RIPEMD160, ... )

* From 2012 onwards SHA-3, a list of candidates:
http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
- SHA-1 should not be used for future systems:
http://www.iaik.tugraz.at/content/research/krypto/sha1/

After all, I don't think one has to be worried about the interleaved
markup, if cryptographically secure hash functions are used, hash values
have enough entropy that if they are concatenated/interleaved with "more
or less arbitrary" markup, one can concatenate/interleave them with
markup. Hash function will perform "lossy" compression of the hash
values plus garbage/markup and still work fine.

Yet, randomized hashing would be a useful addition:

If the creator of the message equals the signer (performing the hashing)
an attacker would even have to attack preimage resistance and 2nd
preimage resistance to attack the hash function ... (If a signer attacks
himself, he would be bound to both colliding messages ... ).

However, if the creator of the message is distinct from the signer
(performing the hashing), the to be hashed document(s) could be prepared
in an off-line manner (collision search can be performed before the
actual signing) and randomized hashing would then make this to an
on-line problem (2nd-preimage search starts at signing time).

Maybe a combination of Random Hashing with RSA-PSS ...

http://www.w3.org/2007/xmlsec/ws/papers/11-mcintosh-ibm/
http://www.w3.org/2007/xmlsec/ws/papers/08-lanz-iaik/

if we have to generate randomness we might do both ..

Best Regards

Konrad

-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
http://www.iaik.tugraz.at/content/about_iaik/people/lanz_konrad/
http://jce.iaik.tugraz.at/sic/products/xml_security

Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm