Maybe common disk encryption is so compromised, there's no point to implementing?

Neil Schneider pacneil at linuxgeek.net
Tue May 6 11:23:21 PDT 2014


The Meeting is Thursday May 8th 7-9 PM at UCSD Extension Mission Valley.
Here's a link to a map to find it.
 http://extension.ucsd.edu/pdf/student/MissionValleyDirections.pdf


On Tue, May 6, 2014 10:08 am, Craig E wrote:
> Thanks Neil.  Yes, the discussion about encryption et al has been
> intriguing.  I am studying to get a Security+ certificate and plan on
> attending the meeting.  Can you remind me/us about the location and time?
> Craig (Ewing)
>
>
> On Tuesday, May 6, 2014 9:41 AM, Neil Schneider <pacneil at linuxgeek.net>
> wrote:
>
>
> Since we don't have a speaker for Thursday night. I suggest we have a
> discussion of encryption. It's been interesting here, should be more
> interesting when we get everyone into one room together.
>
> Will you be there?
>
> On Tue, May 6, 2014 2:49 am, Stewart C. Strait wrote:
>> There are two different scenarios that need to be distinguished.
>>
>> 1. Suppose the attacker can see your disk, but no hibernation file and
>> no swap files, so he can't see the decrypted text or the key or the
>> work the algorithm did. In this case he can't see the structure of the
>> encrypted file or volume unless he does some real cryptanalysis. Even
>> if he thinks he knows exactly which encrypted string corresponds to
>> some known text he needs to do what's called a "known plaintext
>> attack" to get your key, confirm that the string actually corresponds,
>> or get any more text decrypted. There is actually a lot of useful
>> structure, but it's not just obfuscated--you need the key or a lot of
>> crypto insight to detect or use the structure.  If the encryption is
>> 19th century type the attacker will still almost certainly succeed,
>> but that's precisely why those old ciphers are now mainly used for
>> instructional purposes and hobbyist puzzles rather than for serious
>> secrets.
>>
>> 2. If the attacker does have some sort of useful memory dump he's in a
>> very good position. As Andrew said, demanding that the system resist
>> attack under such conditions would be setting a very high bar.  Giving
>> the attacker a memory dump is like stepping out of the room and
>> letting the attacker photograph all your pencil-and-paper decryption
>> work. It's hard to imagine keeping a secret under such
>> conditions. Practically anything you do is only obfuscation because
>> all the secrets must be somewhere in the work, and they must not be
>> too hard to locate or the authorized decryptor can't work.
>>
>> Elcomsoft and Passware need a little time to penetrate this obfuscation,
>> just like with pencil and paper an attacker that steps into your room
>> will need a little work to figure out which part of which piece of paper
>> he needs to look at.
>>
>> It's totally critical to keep the attacker away from your decryption
>> work.  If the system is remembering your passphrase so you don't have
>> to type it in again for the next step of your work, then the system is
>> especially vulnerable.  This isn't news--it's been true at least since
>> the
>> Renaissance. Many crypto software programs modify typical operating
>> system
>> behavior to keep the attacker away from this stuff, at least under some
>> conditions. Making sure that hibernation files and swap files are
>> encrypted
>> or don't include anything for your crypto jobs are typical security
>> measures.
>> If the operating system is too thorough about letting you seamlessly
>> resume
>> your work after interruptions you could conceivably be out of luck.
>>
>> Stewart Strait
>>
>> On Sun, May 04, 2014 at 08:48:17AM -0700, Tony Su wrote:
>>> Stewart,
>>> I think I'm following you and exactly at the point you say
>>>
>>> When you decrypt and enter your
>>> passphrase, the computer looks at the result of decryption--it can tell
>>> whether the padding has the right format.
>>>
>>> That is what is what is being located by a search of the memory dump.
>>> Note
>>> that both Elcomsoft and Passware don't claim to hack working
>>> credentials
>>> immediately, they claim it won't take more than 30 minutes. That's
>>> because
>>> the search algorithm is looking for a particular sequence of characters
>>> that conform with the attributes of what you described... a general
>>> idea
>>> of
>>> string length, maybe a location, maybe a tell-tale header... stuff like
>>> that. And then it tests the candidate. What you describe to me is what
>>> I
>>> categorize as "obfuscation" rather than "encryption" because of the
>>> level
>>> of obscurity, by my definition encryption results in totally
>>> unintelligible
>>> strings whereas obfuscation retains certain characteristics so that
>>> functionality still exists despite its changed appearance. The system
>>> <must> be able to compare input to something to authenticate, and the
>>> string can be either Plain Text because it has been deciphered in
>>> memory
>>> or
>>> is protected only by obfuscation in which case it doesn't matter how
>>> the
>>> string looks, only that it works.
>>>
>>> And, it's at this particular point I don't know that a fundamental
>>> vulnerability can be avoided, granted it requires extraordinary access
>>> (possession of an existing memory dump like hiberfil or a virtual
>>> machine's
>>> memory file, firewire access or the ability to cause a memory dump).
>>>
>>> Tony
>>>
>>>
>>> On Sun, May 4, 2014 at 4:52 AM, Stewart C. Strait
>>> <sstrait1 at san.rr.com>wrote:
>>>
>>> > It's time for an example, using 19th century encryption. The
>>> fundamental
>>> > algorithm will be complete columnar transposition, which will be
>>> explained.
>>> > Let's start without any authentication. Say I want to encrypt
>>> > I#disagree#with#Tony#Su . Say my passphrase is "BARRIER"
>>> >
>>> > BARRIER
>>> > -------
>>> > I#disag
>>> > ree#wit
>>> > h#Tony#
>>> > Su####5
>>> >
>>> > The algorithm adds padding to make a complete rectangle. The only
>>> digits in
>>> > the padding indicate how much padding was added. A whole extra row of
>>> > padding
>>> > is used if there isn't room for at least one pound sign and the
>>> count.
>>> >
>>> > We encrypt by copying the the columns in alphabetical order of their
>>> key
>>> > letters. We copy the leftmost columns first where the key letters are
>>> the
>>> > same.
>>> >
>>> > A:  #e#u
>>> > B:  IrhS
>>> > E:  aiy#
>>> > I:  swn#
>>> > R1: deT#
>>> > R2: i#o#
>>> > R3: gt#5
>>> >
>>> > The encrypted version is #e#uIrhSaiy#swn#deT#i#o#gt#5
>>> >
>>> > So far it's up to the user, when he decrypts, to decide by looking at
>>> the
>>> > decrypted data whether he used the right passphrase. It won't look
>>> like
>>> > English
>>> > if he gets it wrong.
>>> >
>>> > But this is inconvenient, and it won't work if his original data
>>> doesn't
>>> > have
>>> > some obvious visible characteristic like being English.
>>> >
>>> > We can beat this problem if we make the computer add a lot more
>>> padding and
>>> > the algorithm for picking the padding is right. Say the computer
>>> always
>>> > puts
>>> > 5 eight letter dictionary words in the padding.
>>> >
>>> > The computer picks 5 eitht-letter words at random from a dictionary:
>>> >
>>> > senzhary sembilan podagric combated quabirds
>>> >
>>> > BARRIER
>>> > -------
>>> > I#disag
>>> > ree#wit
>>> > h#Tony#
>>> > Su#senz
>>> > hary#se
>>> > mbilan#
>>> > podagri
>>> > c#comba
>>> > ted#qua
>>> > birds##
>>> > #####54
>>> >
>>> > Now you encrypt the same way as before. When you decrypt and enter
>>> your
>>> > passphrase, the computer looks at the result of decryption--it can
>>> tell
>>> > whether the padding has the right format. If not, it gives you an
>>> error
>>> > "Bad Passphrase". If the format is right, it checks its dictionary
>>> for
>>> > the 5 eight-letter words in the pad. It doesn't care which words, as
>>> long
>>> > as they are words somewhere in the dictionary. If it doesn't find
>>> them,
>>> > same error message. If you type the wrong passphrase and by blind bad
>>> luck
>>> > there are still 5 eight-letter words in a correctly formatted pad,
>>> > you are out of luck. The
>>> > computer will accept the wrong passphrase and show you garbled up
>>> data.
>>> > Needless to say this doesn't happen very often (!).
>>> >
>>> > Notice that the computer is verifying your passphrase without ever
>>> > comparing
>>> > it to anything!
>>> >
>>> > Of course this method has kind of poor security even by 19th century
>>> > standards,
>>> > but there isn't any dangerous credential lying around.
>>> >
>>> > Stewart Strait
>>> >
>>> >
>>> > --
>>> > KPLUG-List at kernel-panic.org
>>> > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
>
>>> >
>>>
>>> --
>>> KPLUG-List at kernel-panic.org
>>> http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
>>
>>
>> --
>> KPLUG-List at kernel-panic.org
>> http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
>>
>
>
>
> --
> KPLUG-List at kernel-panic.org
> http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
>
> --
> KPLUG-List at kernel-panic.org
> http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
>




More information about the KPLUG-List mailing list