Author rbcollins
Recipients bkabrda, christian.heimes, dholth, dmalcolm, doughellmann, jpokorny, lukecarrier, pitrou, rbcollins, rpetrov, yolanda.robla
Date 2017-01-17.20:04:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1484683463.1.0.06360604555.issue9216@psf.upfronthosting.co.za>
In-reply-to
Content
@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?
History
Date User Action Args
2017-01-17 20:04:23rbcollinssetrecipients: + rbcollins, pitrou, christian.heimes, rpetrov, doughellmann, dmalcolm, dholth, jpokorny, bkabrda, lukecarrier, yolanda.robla
2017-01-17 20:04:23rbcollinssetmessageid: <1484683463.1.0.06360604555.issue9216@psf.upfronthosting.co.za>
2017-01-17 20:04:23rbcollinslinkissue9216 messages
2017-01-17 20:04:22rbcollinscreate