Michael: Sorry to inform you, but processing power has nothing to do with strengthening a key, that is entirely based on the algorthihm.
Maybe you should check with MK before you put out some of these replies? Cheers, Larry ___________________________________________________ Larry Massey President SECUDE IT Security, LLC 380 Sundown Drive Dawsonville, GA 30534 USA Tel : +1 706 216 8609 Fax: +1 706 216 4696 Mobile : +1 706 215 3854 [EMAIL PROTECTED] www.secude.com |-----Original Message----- |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] |On Behalf Of Michael Jardine |Sent: Tuesday, July 24, 2007 12:20 PM |To: [email protected] |Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use | | Simply put, as processing power increases to decrease the time to |crack a |key, so can that same processing power be increased to strengthen the |key |(or algorithm). So unless something radically changes, the latter will |always remain ahead of the former. And yes, you will have to 'roll |forward.' |The same applies to methods and media for backing up and protecting |digital |data that you do not want encrypted. | | | Regards, | Michael Jardine | SECUDE IT Security | | | -----Original Message----- |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] |On |Behalf Of Allen |Sent: Monday, July 23, 2007 8:44 PM |To: [email protected] |Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use | | 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 | |_______________________________________________ |FDE mailing list |[email protected] |http://www.xml-dev.com/mailman/listinfo/fde _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
