How long to trust 3DES
in [Cryptography]
|
From: Alan on 13 Sep 2006 11:30 Guy Fawkes wrote: > But why are people still using 3DES these days? Isn't AES *much* faster and > *infinitely* more secure? There actually are some applications that were developed before AES was selected and are still in use. AES has not been around all that long.
From: Unruh on 13 Sep 2006 12:28 "Guy Fawkes" <spare_the_rod(a)spoilthechild.com> writes: >But why are people still using 3DES these days? Isn't AES *much* faster and >*infinitely* more secure? faster yes. But why more secure, never mind "infinitely"?
From: Joseph Ashwood on 13 Sep 2006 18:40 "Alan" <a__l__a__n(a)hotmail.com> wrote in message news:1158158645.322349.267720(a)p79g2000cwp.googlegroups.com... > Joseph Ashwood wrote: >> My general rule is that I assume 5-bits (this varies depending on >> situation) >> of advancement and erosion every year when looking to the future, and >> every >> six months I readjust the numbers to fit what actually happened. > > That's an interesting approach. But five bits per year seems very > conservative (Moore's law would suggest one bit every 18 months, > ignoring improvements in methodology). At five bits per year, I would > be projecting 50 bits improvement in attacks over 10 years, which would > render the attack on 3DES more or less equivalent to attacking a 62 bit > key today, or perhaps even a 40 bit key if massive memory is available > enabling memory tradeoffs such as Stefan Lucks described. That's true, but at the same time historically the 5-bits per year has been a functional upper bound. To get an accurate picture you have to revise the outlook periodically. In the longer term this method often ends up narrowly down a use-by date reasonably accurately. The 5-bits isn't necessarily the correct value for your business, it's a matter of other security methods in place, value of data, who the attackers are, methods that would be used, etc. It is not uncommon for the cipher to be the least of the security issues. In your case you need to consider what security threats there are, how capable those threats are, and determine the useful lifetime from there. You didn't ask "How do I justufy continued use of 3DES?" you asked "How long to trust 3DES" there is a difference. > That would > force replacement of 3DES within the next few years ( less than five > years). In most systems the encryption has been isolated to the point where it is a relatively simple matter to perform the change, from there you of course QA the new one, then start rolling out the new one. > While that would be the safe route, I'm not sure I can justify > it based on risk analysis. The probability of 50 bits improvement in > 10 years seems pretty low to me. To me it seems about right, with well-designed ciphers it is unusual that we see a spontaneous advancement of the state-of-the-art that renders it's security useless, instead we see a slow erosion as compute power rises, and attacks become better. The historical rate of advancement approximates about 3-bits per year, with brief periods where we see over 5-bits per year, this inability to predict the frequency is why a conservative estimate is made, and then adjust it mack as we know the past. I would personally not trust 3DES for most work any longer than a decade. Yes, I will certainly be wrong, yes the actual time to break will probably be wrong, but if you follow this, no, your information will not be at significant risk (with good probability). The usual process I recommend is to put in place the decryption of both AES and 3DES, once this is verified, stop producing anything encrypted with 3DES. Since the reencryption is unlikely to offer any useful improvement to the security (backups of the old data leak, compromising security down to the level of the weakest transport used, 3DES) allowing the data to expire naturally is a sustainable business practice. If there are spare computation cycles, it is probably good to reencrypt the old data just for consistency and being able to retire 3DES from the code entirely, but from a security perspective it is not critical. Joe
From: Mike Amling on 13 Sep 2006 15:05 Alan wrote: > In my application (digital video) discovery of a block or two of > plaintext is not a major concern. Discovery of the key or of a > significant viewable segment of the plaintext must be prevented. Our > application uses a separate (3-key) 3DES key + IV for each file, and > are using CBC mode. If you're working with digital video, wouldn't you want a cipher that's faster than 3DES? --Mike Amling
From: Alan on 14 Sep 2006 13:16
> If you're working with digital video, wouldn't you want a cipher > that's faster than 3DES? > > --Mike Amling Without going into the specifics of my application, the speed of the installed base exceeds requirements. Again, this was implemented before AES was chosen. Strength of security was the dominant factor in algorithm choice. Customer acceptance of the choice at that point in time was also critical. |