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

2007-01-20 Thread Peter Gutmann
Victor Duchovni [EMAIL PROTECTED] writes:

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.

Just a word in OpenSSL's defence, see the X.509 Style Guide for the reasoning
behind this.  I don't think any ASN.1-using security toolkit since TIPEM has
done character-set checking, it would fail to verify a large chunk of the
certs out there (I once had a TIPEM user complain to me that they had to stop
using it specifically because it would reject invalid character strings, which
encompassed a nontrivial portion of their user base).

Peter.

-
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-20 Thread Jonathan Thornburg
On Fri, 19 Jan 2007, Bill Stewart wrote:
 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.)
[[...]]
 
 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,

OpenBSD has had swap-space encryption for some years, and recent versions
turn it on in the default install.  I don't know what the other BSDs or
various Linuxen do by default.

OpenBSD's swap encryption uses Rajndael/AES implemented in software.
The performance hit is small on modern hardware, and still acceptable
even on slow hardware (I haven't seen any problems on an old 486/33
laptop I'm using as a home firewall/router).

For laptops (where physical theft is major concern), I think the
combination of an encrypting file system and swap encryption gives a
pretty good -- and readily configurable -- security/performance tradeoff.

ciao,

-- 
-- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED]
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html  
   Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral.
  -- quote by Freire / poster by Oxfam

-
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-20 Thread Victor Duchovni
On Sat, Jan 20, 2007 at 10:10:47PM +1300, Peter Gutmann wrote:

 Victor Duchovni [EMAIL PROTECTED] writes:
 
 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.
 
 Just a word in OpenSSL's defence, see the X.509 Style Guide for the reasoning
 behind this.  I don't think any ASN.1-using security toolkit since TIPEM has
 done character-set checking, it would fail to verify a large chunk of the
 certs out there (I once had a TIPEM user complain to me that they had to stop
 using it specifically because it would reject invalid character strings, which
 encompassed a nontrivial portion of their user base).

I understand the motivation, and agree that this is the right thing to
do, indeed in the application (Postfix) I just map the content to UTF8
(using the identity mapping where appropriate) and then decide what
characters are acceptable, I don't need the original ASN.1 string type
after the string is in canonical form.

My point was that not all the fine details are always documented (even in
closed source libraries with funded documentation teams), and having the
source allows me to move beyond cargo-cult programming and to understand
how to use the library correctly. I guess this is RTFS to extract the
semantics out of the syntax documentation.

In addition, I think that the library should-provide idiot-friendly
interfaces for handling ASN.1 string data holding security sensitive
information (CommonName, subjectAltName, ...), because the code one
finds and copies from other projects is not sufficiently careful.

RFC 3820 suggests that it is OK to consider strings of different ASN.1
types as different content for comparison and then, by implication,
just compare the raw content when the types match, but what one finds
is that applications mostly IGNORE the ASN.1 string type and use the
raw octets for comparison, display, ... and they do that at their peril.

It is also almost universal practice (in C code anyway) to not check
for embedded NUL in the ASN.1 strings, and I wonder how may CAs would
issue eve.biz a cert for alice.com\0..eve.biz? (If the CA's code
handles NUL in octet strings as just another byte, this could happen.

But we digress again, the source is useful in any case, and not just
for full code reviews, used with care it is the ultimate documentation.

-- 

 /\ 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: Private Key Generation from Passwords/phrases

2007-01-20 Thread Travis H.
On Fri, Jan 19, 2007 at 12:11:40AM -0800, Bill Stewart wrote:
 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).

Yes; in textbooks, the author is usually kind enough to give a
complete description of the source; in cryptanalysis, you're usually
looking at the output and making inferences about the source, and
thus, the entropy.

 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.

Actually, my reading of a book on Venona said they captured some
unused OTP on microfilm, but weren't able to use the non-randomness of
the source to decrypt anything.  Someone here mentioned that the
entropy of the plaintext and the OTP have to merely add to 1 to
prevent decryption; the OTP does not necessarily have to provide it
all.  Shannon's estimates were that English prose carries about 1 bit
per symbol.

There were some decrypts of material; the official explanation is that
they recovered a partial codebook and discovered some OTP re-use (the
KGB encoded then superenciphered it).

BTW, dictionary attacks can probably be effectively resisted by
making the hashes of passwords twice as big, and using a random value
concatenated with the password before hashing, and storing it alongside
the hash (it's like crypt(3) salting, but more so).  If the password is
important to keep from disclosure beyond the needs of this security
system, one could even truncate the output of the hash to half its size,
so that there's multiple preimages; since you doubled the hash size to
begin with, you end up with the same security factor against guessing,
I believe.
-- 
``Unthinking respect for authority is the greatest enemy of truth.''
-- Albert Einstein -- URL:http://www.subspacefield.org/~travis/


pgpJoxUCemN6j.pgp
Description: PGP signature


MS responds to Gutmann's Vista paper

2007-01-20 Thread Ivan Krstić
Aside from admitting to increased CPU utilization, which seemed pretty
incontestable anyway, they're disputing [0] many of the points made in
the original paper [1]. Ignoring the hand-wavy arguments, I find most
interesting their claims that a) there will be no move away from unified
drivers, b) that HFS doesn't depend on, and therefore won't impact, open
source drivers, and c) that video quality is degraded only for specific
premium content rather than globally. Assuming all three are true, this
would downgrade the Vista content protection system from
cataclysmically braindead to merely extremely braindead -- a welcome
downgrade, given all of Peter's other points.


[0]
http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/20/windows-vista-content-protection-twenty-questions-and-answers.aspx
[1] http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html

-- 
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D

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


MS responds to Gutmann's Vista paper

2007-01-20 Thread Ivan Krstić
[Perry -- had a clause in there that made no sense; I shouldn't send
mail minutes after waking up. Please discard previous mail and send
along this one.]

[Moderator's note: Too late, sorry. --Perry]

Aside from admitting to increased CPU utilization, which seemed pretty
incontestable anyway, they're disputing [0] many of the points made in
the original paper [1]. Ignoring the hand-wavy arguments, I find most
interesting their claims that a) there will be no move away from unified
drivers, b) that HFS doesn't depend on driver-related video chip
features, and therefore won't impact (the creation of) open source
drivers, and c) that video quality is degraded only for specific premium
content rather than globally. Assuming all three are true, this would
downgrade the Vista content protection system from cataclysmically
braindead to merely extremely braindead -- a welcome downgrade, given
all of Peter's other points.

[0]
http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/20/windows-vista-content-protection-twenty-questions-and-answers.aspx
[1] http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html

-- 
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D

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