[JIRA] Commented: (SSPCPP-366) generated metadata should include cryptographic algorithms

[Scott Cantor (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SSPCPP-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220#comment-14220 ] 

Scott Cantor commented on SSPCPP-366:
-------------------------------------

The reason some of the variants aren't there is due to them not being defined for use with XML. I don't know what the rationale was or is, some of it may just be oversight. But unless a URI is minted for the algorithms, the algorithms can't be used interoperably. They aren't currently in any Santuario versions.

On hashing, I finally found some material noting that SHA-512 is actually faster on 64-bit CPUs, and since the vast majority of CPUs are 64-bit now, I'm inclined to reorder things as 512, 384, 256, 224. That's also more clear to people and will lead to less questions, so the fact that it actually makes some sense is a bonus. (In fact, it's so much faster that NIST just defined new truncated 256 and 224 bit variants of SHA-512 so that people who want shorter lengths don't need to use a slower algorithm.)

On the encryption side, the cipher modes are the main factor, not the bit length. The flaws in CBC are independent of the key size, so AES-128 itself is the same strength in either case, and if we think that's the best choice as a tradeoff, the order would be as I have it (or at least the same between the two sets).

I also think it's fair to say the CBC flaw trumps the attacks on AES at this point in general, so AES-256-GCM > AES-128-CBC.

>From re-reading the layman's guide to the AES mess, I think there's strong reason to consider AES-256 the worst option. AES-128 is arguably as secure if not more because no non-brute force attacks exist yet. AES-192 seems to be in the middle. So ironically, the best ordering there seems to be smallest to largest.


> generated metadata should include cryptographic algorithms
> ----------------------------------------------------------
>
>                 Key: SSPCPP-366
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-366
>             Project: Shibboleth SP - C++
>          Issue Type: Improvement
>          Components: Other
>            Reporter: Ian Young
>            Assignee: Scott Cantor
>            Priority: Minor
>             Fix For: 2.5
>
>   Original Estimate: 1 day
>          Time Spent: 3 hours
>  Remaining Estimate: 5 hours
>
> The service provider should generate metadata describing the cryptographic algorithms supported, per the SAML v2.0 Metadata Profile for Algorithm Support Version 1.0.
> This should include alg:SigningMethod and alg:DigestMethod, as they are the ones we're most likely to need in the shorter term as MD5 and potentially SHA-1 go beyond their useful life.
> There's a note in the wiki that there are problems with OpenSAML-C 2.0 with respect to adding EncryptionMethod elements to KeyDescriptor elements. If this problem is isolated to IdP metadata, we should probably include EncryptionMethod elements as well. If the problem occurs even if EncryptionMethod is present in the metadata for another SP, there's an argument that the SP should not generate EncryptionMethod metadata until we really need it. I'd actually be interested in that clarification myself as at present UK federation checks preclude using EncryptionMethod on both SPs and IdPs, just to be on the safe side.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira