Message285676
@doug - I don't see how a separate fips module *wouldn't* solve it:
- code that uses md5 in security contexts wouldn't be able to call it from the fips module, which is the needed outcome
- code that uses md5 and isn't fips compliant would be importing from the non-fips module, and thats as auditable as looking for a 'usedforsecurity=False' flag
- auditors can assume that code that doesn't use the fips module
And its way less messy: remember we're going to have this flag passed to every hashlib invocation from every project in order to *opt out* of the FIPS restrictions. Because, over time, FIPS will change, so noone can assume that any given function is and will remain FIPS compatible: and this flag is going to percolate up into e.g. the HMAC module.
I think thats pretty ugly: want to calculate the sha of a blob to look it up in git? sha1sum(file.read(), usedforsecurity=False)
Separately I wonder about the impact on higher layers - are they ready to be parameterised by objects, or do they look things up by name - and thus need to start accepting this new parameter and passing it down? |
|
Date |
User |
Action |
Args |
2017-01-17 20:04:23 | rbcollins | set | recipients:
+ rbcollins, pitrou, christian.heimes, rpetrov, doughellmann, dmalcolm, dholth, jpokorny, bkabrda, lukecarrier, yolanda.robla |
2017-01-17 20:04:23 | rbcollins | set | messageid: <1484683463.1.0.06360604555.issue9216@psf.upfronthosting.co.za> |
2017-01-17 20:04:23 | rbcollins | link | issue9216 messages |
2017-01-17 20:04:22 | rbcollins | create | |
|