Michael Jardine wrote: > Pete, > > A brute force attack on an AES-256 encrypted drive that has a STRONG > "Password" or Key would take years. Of course, no one could prevent a > brute-force attack if the attacker gained physical access to the drive in > question - however if the users password (and thus the key) isn't 12345678 > or some other Dilbertian string, then it's realistically impossible to > retrieve the key in a reasonable time frame.
I'm not raising objections just to be querulous, but rather to think ahead for possible corner cases which perhaps should be considered when developing policies. Okay, we all know Moore Law, right? And we all know that the needed lifespan for the encryption is based on the value of the data and the time frame for required protection, Right? For discussion's sake let's assume that HD life is not an issue as bit copies will be made and duplicated as long as is needed to brute force the key. So what kind of data requires long term protection? Obviously plans for attacking someone need to only last until after the attack. The same can be said about almost all business data, be it credit card, billing, marketing, etc. Yes, these might require 20, even 50 year containment, but that is still relatively short. What might need protection for more than 100 years is your DNA data. These days babies are checked at birth and the code could reveal information about you - susceptibility to disease and such - that might be used covertly to discriminate against you in one way or another. Given that I now regularly see obituaries for people over 100. Given the propensity to sue, in the US, at the drop of an imagined injury or defect in disclosure this might mean that you would have to protect DNA data for the lifespan of a person plus sometime afterward to prevent suits against the estate of the person. Add to this that estates seem to last well beyond the natural lifespan in some cases - the current minor flap around Kerouac or how the James Joyce and the Bertholt Brecht estates still attempt to control the use of their literary works are good examples - and the ability of lawyers in the US to create lawsuits I can well imagine that 150 years is not totally unreasonable. Okay, what metric do we apply as a measuring stick for brute force resistance? Let's use the creation of collisions with one of the hash functions as a starting point. The figure as I recall was a space of 2^59 taking 80,000 CPU hours to complete. The machine was a 256 CPU Itanium super computer in 2005. This works to to less than 14 days. Given that the same machine could be constructed with almost 4 times as much power today at a lower cost, how long will it be before it is realistic to crack 256 bits of key space with machines that could be created in 50 years by people with even modest budgets? Even assuming that Moore's law flattens, the price of CPU horsepower does not decline at the rate it has in the last several years, no new time v. effort approaches are thought of or other algorithmic attacks created, it is highly unlikely that the current AES-256 standard would last that long. Given this there are only two ways to protect your data, keep rolling the encryption standard and pray that a copy with a weaker key does not exist, or destruction of the data. Given human fallibility I think the choice is obvious - destruction once the need for access to the data has ended no matter how long that is. Yes, this is a corner case that is highly unlikely to ever happen, but things happen. Look at D.B. Cooper and the 727 exit X. Who would have ever thought you could parachute from a jet and survive? While we don't know if he did survive, we do know that five months later Richard Floyd McCoy, Jr., using the name James Johnson, hijacked United Airlines Flight 855 and also parachuted into the night from its rear stairs with half a million dollars. Yes, McCoy was caught and convicted in federal court in June of 1972 in Salt Lake City, Utah. So you can see there are more possibilities than we have the vision to foresee, so I suggest that we just destroy the data *and* the key. Best, Allen _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
