Pointsec takes advantage of both of these.... Check Point Pointsec
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SafeBoot Simon Sent: Tuesday, July 24, 2007 9:22 PM To: [email protected] Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use Perhaps Michael meant that as the processing power increases, then you naturally can use longer keys to protect data respective of the accepted performance loss? As an example, we were all happy with 512bit RSA lengths a few years ago, now we have smart cards doing 2048bit RSA and most PC's quite happy handling 8k and 16k bit keys.. so, even though a 512bit RSA key is practically factorable now (which it wasnt a few years ago), we've all moved on to longer, practically unfactorable key lengths anyway.. Michael? On Jul 24, 8:37 pm, "Larry Massey" <[EMAIL PROTECTED]> wrote: > 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] > > > > |-----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]://www.xml-dev.com/mailman/listinfo/fde- Hide quoted text - > > - Show quoted text - _______________________________________________ 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
