Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Nov 2013 22:30:57 -0700
From: Kurt Seifried <>
Subject: Re: cryptographic primitive choices [was: Re: Microsoft
 Warns Customers Away From RC4 and SHA-1]

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
Version: GnuPG v1.4.15 (GNU/Linux)


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.