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

Craig E inspecktor2001 at yahoo.com
Tue May 6 10:08:37 PDT 2014


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


More information about the KPLUG-List mailing list