Date: Thu, 14 Nov 2013 22:30:57 -0700 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: cryptographic primitive choices [was: Re: Microsoft Warns Customers Away From RC4 and SHA-1] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So after some though I think what's really needed here is to decide what are safe limits for the encryption/hashing of data. E.g. Using a "weak" encryption algorithm like 3DES for something like an SSL connection to a website for a single banking transaction is a LOT different than using that 3DES to protect the transfer of data that is sensitive in the long term. So some factors to consider: 1) How long is the data sensitive for? Does the sensitivity decay over time or stop being sensitive at some point? Basically is there a time limit on how long the attacker has to decrypt the data for it to be of any use. 2) Is the data transmitted over networks? third party networks? completely random public networks? My bank has no control over where customers log in from for example. Log ins from within a company controlled network can be more tightly controlled. Basically how likely is the data to have been exposed to an attacker? 3) Is the data stored? E.g. an SSL session is typically not stored, but encrypted health records are stored for a long time. So essentially in my head I see a couple slider bars, as they go towards the riskier end of the spectrum (e.g. protecting a CA certificate vs. protecting a single SSL session) stronger encryption is needed. But I'm not sure where to place those limits. Do we come up with something like a CVSS2 score (E.g.: a scenario where the exposure is high, time sensitiveness is low and the data is not stored, so a score of 6.3 which means RC4 is to weak or whatever). I think general rules of thumb are probably ok, like: DES is not safe at all 3DES is not safe for stored data, but may be safe for data transfer that isn't sensitive for a long time and so on. Same goes for hashing algorithms. These would also be useful as software development / configuration guidelines. Thoughts/comments? - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJShbGQAAoJEBYNRVNeJnmTGL0QAMvLf7zuvbK/D1k7d3NCR9pd IaV+6TiL8pHThQrZto7HA5TnFoHm8/uLuKDlzfdE2iFKRH9pcLVGvqtX1v9LW5u+ TYlbcRxmFOg8/nteLgcXYQwkHIDN6LQDFhCQirt7bR01Nw6kWUHWB5CB7DIJE+bs Ox7eT0D08as55fj2dU8QAM6+LAodOZT2qVqkBF+dJiyxi7M1cU2PwCPZIVLTZnh7 lHklTY+O2qs7Dbbjcq65/Lsj+LiyHzHtBu8lpw0SWMnL3octddkI1e8janZRWJbA nq4GmIaG+PTRcHdTgdt5GEV3GqR/WbrKXTTYR9rdM2E3jSBoVMQcx++QL1GRvYYj YgiUwgbpFQZZz9XON7Ghi0IkxekJfqBgVEIoWhcprAYYEqCJNFpLw3tuB7bbCoDR KOA1DF7v19Axy2Vcm6ztNErR2hTIQowwWGpVVzbU8iC0eKm3MKuwun8v2DdS6ZtJ IYozgalGjajhbXPZozO44yNOpuo9nnTyqxFcwUwVG8JEqBcphmA8QQ4SqvwtTfgU ZBmXP9Fv2Gc5QD15ujI4UukcWZs3FP3DS54t2v0P3f7GtPXYtnYz0p7X68V/yu5Z h3susAV10IIEPk5IjNH0Awqf2PCUvKZ2SBhXaEL2PI5LGVP8Q6oT63tuGoO6UwpA dsPTc5PB1cxWd2Z9cAjk =bc4p -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.