Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?

2007-01-19 Thread Victor Duchovni
On Thu, Jan 18, 2007 at 03:57:46PM -0800, Saqib Ali wrote:

 When is the last time you checked the code for the open source app
 that you use, to make sure that it is written properly?
 

Yesterday, in the case of OpenSSL, though I was only looking at how
ASN.1 strings that store the subject CN and subjectAltName deal with
the various possible supported encodings, embedded NUL octets, ...

It took reading the code to determine the following:

- ASN.1 Strings extracted from X.509v3 certs are not validated for
conformance with the declared character syntax. Strings of type
PrintableString or IA5String may hold non-printable or non-ASCII
data.

- Rather in OpenSSL all the ASN.1 string types are opaque TLV byte
arrays, with a manifest type and arbitrary content that may or
not be consisten with the type, and may hold embedded NUL bytes
which require some care in C applications, but at least it *is*
possible if is careful, to check that:

ASN_STRING_length(s) == strlen(ASN1_STRING_DATA(s))

- Conversion to UTF8 is implemented correctly, without prematurely
stopping on internal NUL octets. This also checks that BMPString and
UniversalStrings have encoded lengths that are even or divisible by
4 respectively, and that UTF8 input is valid and minimal.

This means that as a user of the library, I must (and fortunately can):

- Convert the raw ASN.1 encoded data if BMPString or
UniversalString to UTF8.

- Check CommonNames and DNS subjectAltNames for internal NULs,
because I can't rely on no CA to ever mess up and sign a cert for
alice.com\0.eve.com. This check is not found in most sample
applications that (cargo-cult programming rampant in other
problem spaces is also common with SSL).

- Check CommonNames and DNS subjectAltNames for unexpected
non-printable or non-printable characters as appropriate.

This is not the same as a full code review, but having access to the source
means that I can make sure that my code is a correct use of the interface,
that I am not making unfounded assumptions, and there are no obvious bugs
in the part of the library that I am reviewing.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?

2007-01-19 Thread Steve Schear

At 03:57 PM 1/18/2007, Saqib Ali wrote:

When is the last time you checked the code for the open source app
that you use, to make sure that it is written properly?


When is the last time you carefully checked the code for a closed source 
app that you use? (Besides the one you mentioned  to start this thread)


Steve 


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Private Key Generation from Passwords/phrases

2007-01-19 Thread Bill Stewart

At 01:55 PM 1/18/2007, John Denker wrote:

We would be better off maintaining just the one technical
definition of entropy, namely S = sum_i P_i log(1/P_i).
If you want to talk about something else, call it something
else ... or at least make it clear that you are using the
term in a nontechnical or metaphorical sense.
...
If you want to talk about work factor, call it work factor.
If you want to talk about entropy, call it entropy.


One of the roots of the problem is that for many applications,
i is a well-defined event and P(i) is a fixed value (for i) ,
but for many other applications,
i might not be a well-defined event, and/or
P(i) is really a conditional probability, P(i|other-stuff-you-know),
and it's hard to tell whether that's
usefully different from the non-conditional P(i).

One case where this comes up is key generation with entropy pools -
you take a bunch of hopefully-kinda-independent,
hopefully-identically-distributed variables generated
by processes that are complicated enough to look random,
make some estimates of their probability distributions
and hence of their entropy, and add the estimates together,
after prewhitening the samples to make any correlation
harder to exploit.  This gives you N bits of entropy,
and you take M bits of it to use as a key,
again possibly with some hash functions to make
calculations more difficult.

So how many bits of entropy are left?
You can be conservative and call it N-M,
assuming that if somebody were clever enough to take
the M bits key sample they could validate the rest
with only N-M calls to an oracle,
or you could be wildly optimistic and call it N,
assuming that the conditional probabilities of the
remaining pool are still the same given that you know the M bits,
because there's no way to use them to validate anything,
and if you've done a good enough job of designing your
pool management functions the reality is probably
closer to the wildly optimistic case,
unless somebody finds an efficient way to invert your hash functions,
at which point the conditional probabilities are actually
different if you know the M key bits than if you don't.

Another entropy example was the Venona decryptions -
people banging randomly on typewriters didn't actually produce
independent or identically distributed letters,
so the conditional probabilities didn't actually match
the assumed ones, so the entropy estimates were wrong,
and human language plaintext being what it is,
they really needed the 1-bit-per-bit of key entropy.
It's much tougher to exploit than OTPs used more than once,
but it's a start.

But hey, nobody's going to guess that your password
is your dog's name spelled backwards, or think of using
a list of a few million obvious passwords as input to
the key-generation function.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?

2007-01-19 Thread Bill Stewart


As far as Full Disk Encryption's usefulness as a term goes,
I'd distinguish between several different kinds of applications
for encrypting the contents of a disk
1 - The disk drive or maybe disk controller card (RAID, SCSI, etc.)
encrypts all the bits written to the drive
and decrypts all the bits read from the drive,
usually with some keying input from the OS.
2 - The operating system's driver software
encrypts/decrypts all bits written to/from the drive
3 - The operating system's file system driver software
encrypts/decrypts all bits written to/from a file system
(which might or might not occupy a drive partition.)
4 - Utility software encrypts/decrypts bits written to/from directories.
5 - Application software encrypts/decrypts contents of files.

Obviously if you're trying to protect against KGB-skilled attacks
on stolen/confiscated hardware, you'd like to have the swap partition
encrypted as well as any user data partitions, though you may not care
whether your read-only utility software was protected
(e.g. your Knoppix disk or vanilla shared /usr/ or whatever.)
Whether you implement that in the disk controller or OS is really
a matter of convenience and user support economics -
if you're a small conspiracy you may want to roll your own,
but if you're a corporate IT shop, you've probably got economic issues
that affect whether you customize the OS (more) or the disks or both
and it's the operational processes that will trip you up.

On the other hand, if you're trying to protect against
lower-skilled attackers, e.g. laptop thieves who are reselling
disks to the Nigerians and other hardware on eBay,
you want to protect your file systems,
but probably don't need to protect your swap.
It's certainly nice to do that, of course, and might be a Good Thing
for Linux and ***BSD to include in their standard swap drivers,
but hopefully your file system drivers would keep their keys
in non-swappable memory, and most other things get overwritten
often enough that attackers not using electron microscopes
probably won't bother with them much.  In most OS's,
swap isn't persistent across system reboots,
so you can actually generate a new key on the fly every time
and not bother the user about entering it, unlike regular filesystems
or full-disk-encryption systems.

Of course, if the KGB *is* after you, they may black-bag your PC
before they confiscate it - if there's a key-logger chip
added to your keyboard or a camera mounted in your ceiling light,
it may not matter how cool your FDE is.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]