On 4 Apr 2013, at 18:17, "Cantor, Scott" <[email protected]> wrote:
> Ok. Well, 384 and 512 are simply not defined for DSA. At least based on > the most recent algorithm summary I'm aware of: > > http://www.w3.org/2008/xmlsec/Drafts/xmlsec-algorithms/Overview.html The equivalent IETF draft tells the same story: http://datatracker.ietf.org/doc/draft-eastlake-additional-xmlsec-uris/ The standard (FIPS 186-3) does, if I'm reading it correctly, theoretically allow signatures using other approved hash algorithms such as SHA-512: > It is recommended that the security strength of the (L, N) pair and the > security strength of the hash function used for the generation of digital > signatures be the same unless an agreement has been made between > participating entities to use a stronger hash function. When the length of > the output of the hash function is greater than N (i.e., the bit length of > q), then the leftmost N bits of the hash function output block shall be used > in any calculation using the hash function output during the generation or > verification of a digital signature. This is clearly not expected to be something anyone would want to do in a software implementation; that would be why there are no URIs specified for it. I'd guess that it's there to help out people who are building hardware implementations and don't want to build separate SHA-256 and SHA-512 hardware blocks. -- Ian
smime.p7s
Description: S/MIME cryptographic signature
