date:20111201


On 12/02/2011 01:21 AM, Marsh Ray wrote:


Out of a set of 4096 (salt values) random functions each mapping

{ 1...256 } -> { 0 ... 255 }
samples H[0] values

how many would we expect to have all samples map to the same value,
i.e., have a codomain size of 1 ?


s/codomain/image/

- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm


On 12/02/2011 12:25 AM, Solar Designer wrote:

On Thu, Dec 01, 2011 at 11:16:14PM -0600, Marsh Ray wrote:


1. The largest cluster will represent the case where H[0] fails the
comparison in strcmp().

2. The second cluster will be on the order of a few machine cycles
longer,  representing times that H[0] compared successfully.


Yes.


This cluster will be approximately 256 times smaller than the first.


Why not 16 times, if we use hex digits and assume a char-by-char strcmp()?


You're right, I mentally shifted to using bytes instead of hex digits there.


With
4096 trials the expectation is that this cluster will contain about 16
members.


256 with the above correction.


Now that he has a fuzzy idea of which passwords succeed in matching
H[0], he evaluates this set for all 4096 possible salt values. There
will be only one salt value that produces the same H[0] for all of these
passwords.


Did you mean there will _likely_ (but not necessarily) be only one such
salt value?


Very likely I think, even for just a handful of point in cluster 2.

I don't have the exact probability formula for N-way collisions on the 
top of my head right now (or ever really), but maybe we can intuit 
around it in spite of all the paradoxes that apply to collision.


Out of a set of 4096 (salt values) random functions each mapping

 { 1...256 } -> { 0 ... 255 }
  samplesH[0] values

how many would we expect to have all samples map to the same value, 
i.e., have a codomain size of 1 ?


I'm thinking the probability of any one salt value hitting this pattern 
by chance alone is something like


1 / 256^(256 - 2)

Which seems rather small, even times 4096 potential values, even if 
there are some birthday phenomena involved.


Perhaps there are some bored mathematicians on the list who wouldn't 
mind explaining how many samples we'd need (at what timing confidence) 
in order to get a reasonable confidence in the result.


It would also appear that initial set of trial passwords could be 
precomputed along with a graph to direct the search. E.g., Passwords 37 
and 128 look like strong H[0] matches, eliminate 255/256 of the 
candidate salts and proceed with a set of trial passwords that most 
rapidly distinguish between those remaining.



So if his timing data is any good, he has learned the salt


Yes, well done.


Conclusion: Salts placed at the beginning of the password string must
contain sufficient entropy to resist offline brute-force in order to
provide mitigation against timing attacks. It may be better to place
them at the end of the password hash string.


I don't see how placement of the salt in the encoded salt+hash string
matters.  With either placement, the salt characters in the string will
always match because crypt(3) is called with that stored salt.  The fact
that with salt placement at the beginning strcmp() actually does compare
those characters before it gets to comparing H[0] doesn't affect
anything, as far as I can see, assuming a char-by-char strcmp().


Yes, you're right. I remember I went back and forth about in my mind the 
last time I thought about this too.



Am I missing something?


Google seems to turn up a lot of formats with salts that fall well 
within practical brute force range.


- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] No one bothers cracking the crypto (real life edition)

http://pauldotcom.com/2011/11/cracking-md5-passwords-with-bo.html

"BozoCrack is a depressingly effective MD5 password hash cracker with almost 
zero CPU/GPU load. Instead of rainbow tables, dictionaries, or brute force, 
BozoCrack simply finds the plaintext password. Specifically, it googles the MD5 
hash and hopes the plaintext appears somewhere on the first page of results.

It works way better than it ever should."

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm

2011-12-01 Thread Solar Designer

On Thu, Dec 01, 2011 at 11:16:14PM -0600, Marsh Ray wrote:
> On 12/01/2011 10:15 PM, Solar Designer wrote:
> >http://whitepixel.zorinaq.com is probably the fastest single MD5 hash
> >cracker.  This one tests 33.1 billion of passwords per second against a
> >raw MD5 hash on 4 x AMD Radeon HD 5970 (8 GPUs).  Of course, the
> >passwords being tested are not arbitrary (e.g., you can't just feed a
> >wordlist to such a cracker), although the character set is configurable.
> 
> Where would you find a wordlist to keep it busy for more than a 
> millisecond anyway?

Not a plain wordlist, but wordlist + thousands or millions of rules.
In fact, another tool implements that and achieves just slightly slower
speeds: http://hashcat.net/oclhashcat-plus/

> >1. Already discussed: implement constant-time comparisons by using XORs
> >and ORs.
> 
> Talking with people who work closely with code generation convinced me 
> that it's essential to examine the generated code. A compiler might 
> recognize and exploit the opportunity for early loop termination.

That's correct.

> >2. Pass both strings to compare through an HMAC with a secret.  If one
> >of the strings is a secret, then that secret may be reused for this HMAC
> >as well.
> 
> http://www.isecpartners.com/blog/2011/2/18/double-hmac-verification.html

Yes, Nate had pointed me at this one too.

> >It'd be curious to explore how much entropy in the salt is needed for
> >this.  Are 12-bit salts of traditional DES-based crypt(3) sufficient
> >against remote timing attacks or not?
> 
> Let's assume crypt(3) returns a string which is compared against the 
> expected value using strcmp(), and the salted hash is formed of hex 
> digits like:
> 
> %crypt(3)%SSS%%
> 
> SSS - 12 bit salt
> HHH - 64 bit value from DES-like function

OK, let's assume this.

> (I know it uses $ and some form of base-64 in practice,

For traditional DES-based crypt(3), it is 13 characters:

sshhh

There's no fixed part, just two characters of salt and 11 of hash (using
a base-64 character set).

But let's continue to assume your format for the string for now:

> The attacker generates, say, 4096 random passwords and accurately times 
> their evaluation. If there isn't too much jitter on the network (or the 
> local machine), and his timing measurements are accurate enough, he will 
> observe the timings grouping into two clusters:
> 
> 1. The largest cluster will represent the case where H[0] fails the 
> comparison in strcmp().
> 
> 2. The second cluster will be on the order of a few machine cycles 
> longer,  representing times that H[0] compared successfully.

Yes.

> This cluster will be approximately 256 times smaller than the first.

Why not 16 times, if we use hex digits and assume a char-by-char strcmp()?

> With 
> 4096 trials the expectation is that this cluster will contain about 16 
> members.

256 with the above correction.

> Now that he has a fuzzy idea of which passwords succeed in matching 
> H[0], he evaluates this set for all 4096 possible salt values. There 
> will be only one salt value that produces the same H[0] for all of these 
> passwords.

Did you mean there will _likely_ (but not necessarily) be only one such
salt value?

> So if his timing data is any good, he has learned the salt

Yes, well done.

> Conclusion: Salts placed at the beginning of the password string must 
> contain sufficient entropy to resist offline brute-force in order to 
> provide mitigation against timing attacks. It may be better to place 
> them at the end of the password hash string.

I don't see how placement of the salt in the encoded salt+hash string
matters.  With either placement, the salt characters in the string will
always match because crypt(3) is called with that stored salt.  The fact
that with salt placement at the beginning strcmp() actually does compare
those characters before it gets to comparing H[0] doesn't affect
anything, as far as I can see, assuming a char-by-char strcmp().

Am I missing something?

Alexander
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

Ben Laurie  writes:

>They appear to actually be selling sub-RA functionality, but very hard to
>tell from the press release.

OK, so it does appear that people seem genuinely unaware of both the fact that
this goes on, and the scale at which it happens.  Here's how it works:

1. Your company or organisation is concerned about the fact that when people
go to their site (even if it's an internal, company-only one), they get scary
warnings.

2. Your IT people go to a commercial CA and say "we would like to buy the
ability to issue padlocks ourselves rather than having to buy them all off
you".

3. The CA goes through an extensive consulting exercise (billed to the
company), after which they sell the company a padlock-issuing license, also
billed to the company.  The company is expected to keep records for how many
padlocks they issue, and pay the CA a further fee based on this.

4. Security is done via the honour system, the CA assumes the company won't do
anything bad with their padlock-issuing capability (or at least I've never
seen any evidence of a CA doing any checking apart from for the fact that
they're not getting short-changed).

This is why in the past I've repeatedly referred to "unknown numbers of
unknown private-label CAs", we have absolutely no idea how many of these
private-label CAs are out there or who they are or who controls them, but
they're probably in the tens, if not hundreds, of thousands, and many are
little more than a Windows server on a corporate LAN somewhere (and I mean
that literally, it was odd to sit in front of a Windows 2000 box built from
spare parts located in what used to be some sort of supplies closet and think
"I can issue certs that chain to $famous_ca_name from this thing" :-).

Going through the process is like getting a BS 7799 FIPS 140 certification,
you pay the company doing the work to get you through the process, and you
keep paying them until eventually you pass.  The only difference is that while
I've heard of rare cases of companies failing BS 7799, I've never heard of
anyone failing to get a padlock-issuing license.

Are people really not aware of this?  I thought it was common knowledge.  If
it isn't, I'll have to adapt a writeup I've done on it, which assumes that
this is common knowledge.

Peter.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Newbie Question

On 12/01/2011 11:11 PM, Sampo Syreeni wrote:

On 2011-12-01, Randall Webmail wrote:

I am an almost-complete greenie WRT crypto, which is why I'm here
to learn.

What is the proper thing to do when one of those things pops up?
(It is NOT a rare event).

They mostly mean you no harm.

You don't know that.

For all we know, Randall Webmail is someone who posted something
derogatory about the King or El Presidente and when the Honor Police get
on his Facebook they're going to round up all his friends along with him.

Or he's sitting comfortably in his quite suburban home and he happens to
have one of the estimated 1M home routers that are pwned or 1M PCs with
the dnschanger trojan and his banking session is being redirected to a
hostile server.

http://www.eweek.com/c/a/Security/Researchers-Discover-Link-Between-TDSS-Rootkit-and-DNSchanger-Trojan-753018/

So just accept/except.

This is not good advice.

But always bear in mind that it *could* be a man-in-the-middle
attack.

All legitimate secure sites have a valid certificate, or the site is
horribly broken.

If you ask for a secure site, and are presented with a certificate that
was not issued to the legitimate site, it *is* a man-in-the-middle
attack, by definition.

Just because you're staying in a hotel does not mean that you must allow
that hotel to intercept your secure communications. Furthermore, you
probably have know way of knowing that it even is the hotel that's
intercepting you. Hotel networks are not known for themselves being
secure, and authentication systems tend not to degrade gracefully.

- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

Marsh Ray  writes:

> Certificate Authority (CA) to Chain to GeoTrust's Ubiquitous Public
> Root
>
>[...]
>
> SAN FRANCISCO, RSA CONFERENCE, Feb. 14

February of which year?  If it's from this year then they're really late to
the party, commercial CAs have been doing this for more than a decade.  These
things are huge money-earners for them, they start at around $50K per sub-CA
cert and go from there, and because you have to do this to turn off the
browser warnings, large numbers of companies do it.  I don't know about actual
figures, but from stories I've heard it wouldn't surprise me if many CAs made
the majority of their income from selling padlocks [0] to companies rather
than selling them to web sites.

Or is GeoRoot some novel new thing that I'm not familiar with?

Peter.

[0] By "selling padlocks" I mean you give them money and people who come to
your site get to see a padlock picture.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Newbie Question

On Dec 1, 2011, at 8:43 PM, Randall Webmail wrote:

> From: "ianG" 
> 
> >It does store certs.  It just takes above & beyond to get at them.  
> Unknown whether it stores certs that you reject.
> 
> I spend a lot of time in hotels, and it is VERY common for me to get one of 
> those popups complaining about certificates when I connect to the hotel WiFi.
> 
> I am an almost-complete greenie WRT crypto, which is why I'm here to learn.
> 
> What is the proper thing to do when one of those things pops up?   (It is NOT 
> a rare event).
> 
> I use the "https everywhere" firefox extension on my OSX laptop.   I do not 
> access my bank accounts on public WiFi, but I really don't have a choice but 
> to access webmail and gmail.What should I do when I get one of those cert 
> warnings?

Click "Cancel" and then try again.

The usual reason for the message is that some network client has bumped up 
against the captive portal and gotten either a network error or something that 
is an HTTP response and thus a completely protocol illegal answer. They then 
interpret it as an SSL error when it's really nothing but the captive portal.

But you want to click cancel, because if there's someone who wants to hack you, 
that's how they'd do it.

Jon

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Newbie Question

Randall Webmail  writes:

>What is the proper thing to do when one of those things pops up? (It is NOT a
>rare event).

Go to the security settings dialog in your browser, go to "Export certificate"
(or whatever your browser uses), select "Certificate chain / PKCS #7", and
then post it to this list.

Peter :-).

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm


On 12/01/2011 10:15 PM, Solar Designer wrote:

On Thu, Dec 01, 2011 at 09:15:05PM -0600, Marsh Ray wrote:

When you can evaluate MD5 at 5.6 GH/s, accessing even a straight lookup
table in main memory is probably a slowdown.


Yes, but those very high speeds are throughput for large numbers of
hashes to compute in parallel.  If you don't yet have a large enough
number of inputs to hash (that is, if you have an algorithm with
conditional branching), then you'd achieve a lower speed.


Either way, it's overkill for finding candidate passwords for H[1], 
H[2], and probably H[3] and H[4]. (If the password even holds out that 
long).



http://whitepixel.zorinaq.com is probably the fastest single MD5 hash
cracker.  This one tests 33.1 billion of passwords per second against a
raw MD5 hash on 4 x AMD Radeon HD 5970 (8 GPUs).  Of course, the
passwords being tested are not arbitrary (e.g., you can't just feed a
wordlist to such a cracker), although the character set is configurable.


Where would you find a wordlist to keep it busy for more than a 
millisecond anyway?



1. Already discussed: implement constant-time comparisons by using XORs
and ORs.


Talking with people who work closely with code generation convinced me 
that it's essential to examine the generated code. A compiler might 
recognize and exploit the opportunity for early loop termination.



2. Pass both strings to compare through an HMAC with a secret.  If one
of the strings is a secret, then that secret may be reused for this HMAC
as well.


http://www.isecpartners.com/blog/2011/2/18/double-hmac-verification.html

It may be relevant that in this case it isn't specified which of the two 
parameters 'digest' and 'secret' are unknown to the attacker.



It'd be curious to explore how much entropy in the salt is needed for
this.  Are 12-bit salts of traditional DES-based crypt(3) sufficient
against remote timing attacks or not?


Let's assume crypt(3) returns a string which is compared against the 
expected value using strcmp(), and the salted hash is formed of hex 
digits like:


%crypt(3)%SSS%%

SSS - 12 bit salt
HHH - 64 bit value from DES-like function

(I know it uses $ and some form of base-64 in practice, but the relevant 
factor is that the salt comes before the hash value, and everything else 
before H[0] is fixed and known to the attacker.)


The attacker generates, say, 4096 random passwords and accurately times 
their evaluation. If there isn't too much jitter on the network (or the 
local machine), and his timing measurements are accurate enough, he will 
observe the timings grouping into two clusters:


1. The largest cluster will represent the case where H[0] fails the 
comparison in strcmp().


2. The second cluster will be on the order of a few machine cycles 
longer,  representing times that H[0] compared successfully. This 
cluster will be approximately 256 times smaller than the first. With 
4096 trials the expectation is that this cluster will contain about 16 
members.


Now that he has a fuzzy idea of which passwords succeed in matching 
H[0], he evaluates this set for all 4096 possible salt values. There 
will be only one salt value that produces the same H[0] for all of these 
passwords. It's possible that some of his values crept into the wrong 
cluster, but these can be readily ignored if, say, 10 of the 16 produce 
a match. 16*4096 is not very much work at all, and most of it can be 
skipped.


So if his timing data is any good, he has learned the salt and can 
quickly verify it with some confirming tests. The attacker proceeds to 
work out the remainder of the password hash as before.


Conclusion: Salts placed at the beginning of the password string must 
contain sufficient entropy to resist offline brute-force in order to 
provide mitigation against timing attacks. It may be better to place 
them at the end of the password hash string.



 (Assuming that these salts are
otherwise perfect.)  They appear to have been sufficient in practice so
far (I haven't heard of anyone mounting such an attack), but there's
room for some research and testing here (likely proving that slightly
larger salts or constant-time comparisons are desirable for this).


(*_*);;;

- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

Adam Back  writes:

>Surely the SSL Observatory has these MitM sub CA certs if they exist in the
>wild and are being used to create real time MitM certs for domains the issuer
>certainly doesnt own.

You have to be inside the captive portal to see these blue-pill certs.  This 
is why various people have asked for samples, because only a select lucky few 
will be able to experience them in the wild.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Newbie Question

2011-12-01 Thread Sampo Syreeni


On 2011-12-01, Randall  Webmail wrote:

I am an almost-complete greenie WRT crypto, which is why I'm here to 
learn.


What is the proper thing to do when one of those things pops up?   (It 
is NOT a rare event).


They mostly mean you no harm. So just accept/except. But always bear in 
mind that it *could* be a man-in-the-middle attack. If they were out to 
get you, you know? They could be, without any reason at all, simply 
because they can and it's cheap. For further purposes some 20a down the 
hill.


Personally, my stuff is in the open. Even painfully so. I mostly play by 
Brin's open society rules. But most can't do that. So, be afraid, be 
very afraid.


I use the "https everywhere" firefox extension on my OSX laptop. I do 
not access my bank accounts on public WiFi, but I really don't have a 
choice but to access webmail and gmail.  What should I do when I get 
one of those cert warnings?


Did you ever divulge your name online? Your birthdate to a now-angry 
girlfriend, or perhaps facebook? Your social security number to an 
employer who might be willing to give it up for a price? Your PIN code 
to anybody at all who might change their opinion? Sure you weren't being 
wathced there?


Obviously if you didn't do any of that, it's just the first, most 
simplest thing you should have done unless you want yourself fully in 
the open. Personally, I don't mind much. But you might. ;)

--
Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Newbie Question

2011-12-01 Thread Randall Webmail

From: "ianG"  

>It does store certs. It just takes above & beyond to get at them. 
Unknown whether it stores certs that you reject. 

I spend a lot of time in hotels, and it is VERY common for me to get one of 
those popups complaining about certificates when I connect to the hotel WiFi. 

I am an almost-complete greenie WRT crypto, which is why I'm here to learn. 

What is the proper thing to do when one of those things pops up? (It is NOT a 
rare event). 

I use the "https everywhere" firefox extension on my OSX laptop. I do not 
access my bank accounts on public WiFi, but I really don't have a choice but to 
access webmail and gmail. What should I do when I get one of those cert 
warnings? 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm

2011-12-01 Thread Solar Designer

On Thu, Dec 01, 2011 at 09:15:05PM -0600, Marsh Ray wrote:
> When you can evaluate MD5 at 5.6 GH/s, accessing even a straight lookup
> table in main memory is probably a slowdown.

Yes, but those very high speeds are throughput for large numbers of
hashes to compute in parallel. If you don't yet have a large enough
number of inputs to hash (that is, if you have an algorithm with
conditional branching), then you'd achieve a lower speed.

> Solar might have hard numbers.

http://whitepixel.zorinaq.com is probably the fastest single MD5 hash
cracker. This one tests 33.1 billion of passwords per second against a
raw MD5 hash on 4 x AMD Radeon HD 5970 (8 GPUs). Of course, the
passwords being tested are not arbitrary (e.g., you can't just feed a
wordlist to such a cracker), although the character set is configurable.

Anyway, back to the original topic, I think there are two primary ways
of fixing the code:

1. Already discussed: implement constant-time comparisons by using XORs
and ORs.

2. Pass both strings to compare through an HMAC with a secret. If one
of the strings is a secret, then that secret may be reused for this HMAC
as well. Then compare the HMACs. So instead of a direct comparison like:

if (token == secret)

you do:

if (HMAC(secret, token) == HMAC(secret, secret))

In fact, I think HMAC is an overkill for this - simple concatenation of
inputs to a crypto hash will do as well. (Length extension attacks do
not apply here when the secret length is constant.)

http://openwall.info/wiki/people/solar/algorithms/challenge-response-authentication#Timing-attacks

Nate Lawson pointed out a few theoretical problems with this to me in a
private e-mail exchange, but none of those apply when the expected_response
length is a constant and is not secret. (That is, expected_response
value is secret, but its length is e.g. the constant 16.) Otherwise
this length value may be leaked, and length extension attacks might be
possible as well.

BTW, a similar thing (to what I proposed above) happens when
authenticating with a plaintext password against a salted hash.
As far as I'm aware, historically the salt was never intended to serve
for this purpose, but it happens to mitigate timing attacks on
comparison of the hashes (e.g., crypt(3) output strings) as long as it's
stored along with the hash (not revealed separately) and not guessed by
a remote attacker (who doesn't readily have a copy of the hash anyway).
It'd be curious to explore how much entropy in the salt is needed for
this. Are 12-bit salts of traditional DES-based crypt(3) sufficient
against remote timing attacks or not? (Assuming that these salts are
otherwise perfect.) They appear to have been sufficient in practice so
far (I haven't heard of anyone mounting such an attack), but there's
room for some research and testing here (likely proving that slightly
larger salts or constant-time comparisons are desirable for this).

Alexander
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm


On 12/01/2011 06:15 PM, Jerrie Union wrote:



How should the attacker mount the attack after hash[0] has been recovered?


He tests passwords that yield the identified H[0].


I guess for a given digest D if the attacker guess the character at position 1 
(D[1])
  by supplying the secret S there’s no easy way to recover D[2] because the md5
function will introduce noise in every single bit of the output as you change a 
single
bit in the input.


He could generate random passwords and discard 254/255 of them. This 
should not be a limitation as MD5s can be generated by the millions per 
second (said to be giga/s with GPGPU rigs).

http://www.golubev.com/hashgpu.htm

He only needs to find 256 of them to probe for the next value.


Maybe, by having a huge precomputed table the attacker can attempt to mount a 
timing attack
in this way:
1. guess the first byte of the digest by exploiting the timing attack
2. for every digest in the rainbow table starting with the previously guessed 
byte:
3. try to send the plaintext and time the response to recover the second byte

The same process could be iterated until the fully string is recovered.

Does it make sense?


Except that the rainbow table is unnecessary and the precomputed table 
doesn't need to be very big.


When you can evaluate MD5 at 5.6 GH/s, accessing even a straight lookup 
table in main memory is probably a slowdown.


Solar might have hard numbers.

- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm

On Dec 1, 2011, at 3:53 PM, Alfonso De Gregorio wrote:

> 
> If the attacker has direct control over the challenge/digest, the side
> channel may turn to be observable. The attacker could query adaptively
> the authentication server and exploit the timing information to
> recover the hashed secret - gaining access. If the hash is not salted,
> a secret preimage can be found with a TMTO attack.
> 

Potentially yes, indeed. But the logic that you use to prevent that might also 
have timing issues.

If I were writing in C, I might do something slightly evil like just compare 16 
bytes regardless, but that could give problems in a language like Java, which 
might take an exception if the challenge is short. There's the additional 
problem that unless you compare an algorithm ID, too, there's the chance that 
you'd get a cross-hash collision (one were the first 16 bytes of SHA256 matches 
the MD5), even. I didn't even address the question of why MD5 was being used 
for this without an HMAC, as I took that as a constraint.

It also occurred to me that there are architectures where 
comparison/subtraction isn't constant time (a negative result takes an extra 
micro-op) and if you're really anal, you should use an idiom like:

failure |= x ^ y;

and compare to zero at the end. You could even do this with sizes larger than a 
byte, if you can somehow cast a byte array into something larger, and then just 
inline the whole thing.

So it's really a more involved question than it appears on first blush -- and 
that's why crypto is hard!

Jon

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm

2011-12-01 Thread Jerrie Union

On Dec 1, 2011, at 11:48 PM, Marsh Ray wrote:

> On 12/01/2011 04:37 PM, Jerrie Union wrote:
>> 
>> public boolean check(digest, secret) {
>>   hash = md5(secret);
>> 
>>   if (digest.length != hash.length)  {
>> return false;
>>   }
>> 
>>   for (i = 0; i<  digest.length; i++) {
>> if (digest[i] != hash[i]) {
>>   return false;
>> }
>>   }
>> 
>> I’m wondering, if it’s running as some authenticated server application, if
>> it should be considered as resistant to time attacks nowadays.
> 
> Not resistant. It's a timing oracle. Very dangerous.

How should the attacker mount the attack after hash[0] has been recovered?
I guess for a given digest D if the attacker guess the character at position 1 
(D[1])
 by supplying the secret S there’s no easy way to recover D[2] because the md5
function will introduce noise in every single bit of the output as you change a 
single
bit in the input.

Maybe, by having a huge precomputed table the attacker can attempt to mount a 
timing attack 
in this way:
1. guess the first byte of the digest by exploiting the timing attack
2. for every digest in the rainbow table starting with the previously guessed 
byte:
3. try to send the plaintext and time the response to recover the second byte

The same process could be iterated until the fully string is recovered. 

Does it make sense?

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

2011-12-01 Thread Nico Williams

On Thu, Dec 1, 2011 at 5:11 PM, Adam Back  wrote:
> btw if client certs are being used or TLS-SRP ciphersuite these attacks
> would not work because SSL negotiation would fail.  Unless the MitM could
> create fake client certs on the fly also that would be acceptable to the
> server.

Right, because those involve a channel binding (internal to the channel itself).

OBC doesn't detect the MITM though if the MITM re-writes the cookies
in the requests and responses.  In particular, if passwords are POSTed
in forms, the MITM gets them, though if origin bound cookies are
already in use by that point then the MITM has to rewrite them.

Nico
--
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm

2011-12-01 Thread Alfonso De Gregorio

On Fri, Dec 2, 2011 at 12:31 AM, Jon Callas  wrote:
>
> On Dec 1, 2011, at 2:37 PM, Jerrie Union wrote:
>
>> I’m wondering, if it’s running as some authenticated server application, if
>> it should be considered as resistant to time attacks nowadays. I’m aware 
>> that’s
>> not a good practice, but I’m not clear if I should consider it as 
>> exploitable over the
>> network (on both intranet and internet scenarios).
>>
>> I would like to run some tests, but I’m not sure if I should follow some 
>> specific
>> approach. Anyone has done some research recently?
>
> I agree with Ian. You have correctly observed that the check algorithm is not 
> constant time. This is a flaw. But you're doing a hash, and consequently that 
> flaw may not be observable. It is therefore a very small flaw.

If the attacker has direct control over the challenge/digest, the side
channel may turn to be observable. The attacker could query adaptively
the authentication server and exploit the timing information to
recover the hashed secret - gaining access. If the hash is not salted,
a secret preimage can be found with a TMTO attack.

-- alfonso     blogs at http://Plaintext.crypto.lo.gy   tweets @secYOUre
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm


On 12/01/2011 04:37 PM, Jerrie Union wrote:


public boolean check(digest, secret) {
   hash = md5(secret);

   if (digest.length != hash.length)  {
 return false;
   }

   for (i = 0; i<  digest.length; i++) {
 if (digest[i] != hash[i]) {
   return false;
 }
   }

I’m wondering, if it’s running as some authenticated server application, if
it should be considered as resistant to time attacks nowadays.


Not resistant. It's a timing oracle. Very dangerous.


I’m aware that’s
not a good practice, but I’m not clear if I should consider it as exploitable 
over the
network (on both intranet and internet scenarios).


Nate Lawson has some great resources on his blog.
http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/

"Further research in 2007 showed that differences as small as 20 
microseconds over the Internet and 100 nanoseconds over the LAN could be 
distinguished with about 1000 samples."


For example,

http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/


A lot depends on the specifics of course. For example, can the attacker 
supply the "digest" directly? A lot of message authentication schemes 
seem to involve that type of thing (e.g., using HMAC instead of plain MD5).


Or perhaps the attacker supplies the 'secret', as in a 
password-validation routine. (Of course that's not the only problem in 
this routine for doing password validation). The attacker could supply 
various passwords. He knows the MD5s of the values he supplies. The 
timing comparison tells him how many bytes of the hash he has correct.


Although it would be difficult for him to do a full primary preimage 
attack on MD5 itself needed to extract the full hash value via timing, 
he probably would not have to. He just needs to work out the first few 
bytes of the hash value to enable an offline dictionary attack. E.g. 
Just by learning the first two bytes he can eliminate 65535/65536ths of 
the possible passwords.



I would like to run some tests, but I’m not sure if I should follow some 
specific
approach. Anyone has done some research recently?


I pointed this out as a potential problem in Tor.
https://trac.torproject.org/projects/tor/ticket/3122
They promptly fixed it
https://gitweb.torproject.org/tor.git/history/HEAD:/src/common/di_ops.c
and did some timing statistical tests on their data-independent memcmp() 
implementation. NickM links to some timing test code in one of the 
comments (not in Java though).


The right approach is to find a well-tested timing-independent library 
for your platforms and use it. Inspect the generated code to be sure it 
does what you're expecting (compilers can be surprisingly clever at 
optimizing things you want to be slow).


- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm

On Dec 1, 2011, at 2:37 PM, Jerrie Union wrote:

> I’m wondering, if it’s running as some authenticated server application, if 
> it should be considered as resistant to time attacks nowadays. I’m aware 
> that’s
> not a good practice, but I’m not clear if I should consider it as exploitable 
> over the
> network (on both intranet and internet scenarios). 
> 
> I would like to run some tests, but I’m not sure if I should follow some 
> specific
> approach. Anyone has done some research recently?

I agree with Ian. You have correctly observed that the check algorithm is not 
constant time. This is a flaw. But you're doing a hash, and consequently that 
flaw may not be observable. It is therefore a very small flaw. 

I might rewrite the routine differently than Ian did. Let me apologize in 
advance for being a C guy writing Java, but I'd do approximately this:

public boolean check(digest, secret) {
 int failure = 0;
 hash = md5(secret);

 failure |= (digest.length != hash.length);   // Is the hash of the same 
length?

 for (i = 0; i < min(digest.length, secret.length); i++) {  

failure |= (digest[i] != hash[i]);  // Check each byte for non-match
 }   

 return failure == 0;   // return true if we didn't fail. Yeah, confusing.
} 

I don't guarantee that this works, but it looks okay from here. The intent is 
that you always OR together a length check and each byte check, with a 
low-order 1 bit indicating a failure. Then you reverse polarity and convert to 
a boolean. I hope I didn't embarrass myself in this pseudocode.

You have to have a wart in one of two places. I chose to have a wart that if 
the sizes mismatch, you still do the byte checks. Alternatively, if you return 
early on a size mismatch, you leak a size mismatch, which is small potatoes in 
the grand scheme of things. My way of doing it leaks the size mismatch and its 
size if you can somehow force in a secret of variable size. I went back and 
forth on which is better and decided I don't care at the end.

I don't think there's anything wrong with what Ian did, but I stuck to having 
most of my work be an OR because I'm that paranoid.

Jon
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm

2011-12-01 Thread Alfonso De Gregorio

On Thu, Dec 1, 2011 at 11:37 PM, Jerrie Union  wrote:
>
> Given the following Java code:
>
> public boolean check(digest, secret) {
>      hash = md5(secret);
>
>      if (digest.length != hash.length)  {
>        return false;
>      }
>
>      for (i = 0; i < digest.length; i++) {
>        if (digest[i] != hash[i]) {
>              return false;
>        }
>      }
>
>      return true;
> }
>
> I’m wondering, if it’s running as some authenticated server application, if
> it should be considered as resistant to time attacks nowadays. I’m aware 
> that’s
> not a good practice, but I’m not clear if I should consider it as exploitable 
> over the
> network (on both intranet and internet scenarios).

You should.

The code above leaks timing information and becomes exploitable, given
enough measurements.

(also, consider not storing the secret in plaintext)

> I would like to run some tests, but I’m not sure if I should follow some 
> specific
> approach. Anyone has done some research recently?

Sebastian Schinzel. Presenting his research on December 28th, at 28C3:
Time is on my Side - exploiting timing side channel vulnerabilities on
the web: http://events.ccc.de/congress/2011/Fahrplan/events/4640.en.html

Cheers,

-- alfonso blogs at http://Plaintext.crypto.lo.gy   tweets @secYOUre
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

2011-12-01 Thread Adam Back

It does at least say they need a certificate practice statement, and
hardware key generation and storage, AND "All domains must be owned by the
enterprise customer". They can sell the ability to be a sub-CA if they want
to. There standards seem probably as good as your average CA and precludes
MitM applications.

GeoRoot would seem to preclude what Greg thinks he saw Boingo do.

Surely the SSL Observatory has these MitM sub CA certs if they exist in the
wild and are being used to create real time MitM certs for domains the
issuer certainly doesnt own.

I'd like to know which CAs if any are issuing these sub CA certs (so I can
remove them). It would be intereseting to see what label they put on the
certs also.

btw if client certs are being used or TLS-SRP ciphersuite these attacks
would not work because SSL negotiation would fail. Unless the MitM could
create fake client certs on the fly also that would be acceptable to the
server.

Adam

On Thu, Dec 01, 2011 at 05:59:23PM +, Ben Laurie wrote:

http://www.trustico.com/material/DS_GeoRoot_0205.pdf

Well, we'll only break the dishonest ones :-)

On Thu, Dec 1, 2011 at 5:48 PM, Marsh Ray wrote:

On 12/01/2011 11:09 AM, Ben Laurie wrote:

On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray
wrote:

http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html

They appear to actually be selling sub-RA functionality, but very
hard to tell from the press release.

Bottom line: I'm going to believe this one someone displays a cert
chain.

Translated:

GeoRoot is only available for internal use, and organizations must
meet certain eligibility requirements, [...] compliance guidelines,
and hardware security specifications.

Organizations must maintain a list Certificate Revocation List (CRL)

for all certificates issued by the company.

But don't worry, Mozilla has a "checklist" for sub-CAs!

https://wiki.mozilla.org/CA:SubordinateCA_checklist

Home » CA:SubordinateCA_checklist

Terminology

The following terminology will be used in this wiki page regarding
subordinate CAs.

Third-Party: The subordinate CA is operated by a third party external
to the root CA organization; and/or an external third party may
directly cause the issuance of a certificate within the CA
hierarchy.

Third-party private (or enterprise) subordinate CAs: This is the case
where a commercial CA has enterprise customers who want to operate
their own CAs for internal purposes, e.g., to issue SSL server
certificates to systems running intranet applications, to issue
individual SSL client certificates for employees or contractors for
use in authenticating to such applications, and so on.

* These sub-CAs are not functioning as public CAs, so typical Mozilla
users would not encounter certificates issued by these sub-CAs in

s/would/should/

their normal activities.
* For these sub-CAs we need assurance that
they are not going to start functioning as public CAs.

As Dan would say, security comes from this "absence of the potential" for
this type of surprise.

This is not security, this reliance.

Currently the
only assurances available for this case it to ensure that these third
parties are required to follow practices that satisfy the Mozilla CA
Certificate Policy, and that these third parties are under an
acceptable audit regime.

Promises, promises.

o In Bug #394919 NSS is being updated to
apply dNSName constraints to the CN, in addition to the SANs.
o We
plan to update our policy to require CAs to constrain third-party
private (or enterprise) subordinate CAs so they can only issue
certificates within a specified domain. See section 4.2.1.10 of RFC
5280.

Someday.

To be fair to Mozilla, at least they're the ones with an open policy about
it. I didn't find such a policy for the other popular web clients (I may not
have looked hard enough).

- Marsh

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Digest comparison algorithm

2011-12-01 Thread ianG


On 2/12/11 09:37 AM, Jerrie Union wrote:

I’m wondering, if it’s running as some authenticated server application, if
it should be considered as resistant to time attacks nowadays. I’m aware that’s
not a good practice, but I’m not clear if I should consider it as exploitable 
over the
network (on both intranet and internet scenarios).


You're doing a digest first, so the remaining code is in the noise 
level.  And even if it comes back with some detectable difference, 
what's it telling you?  You can't look back from the bit position of the 
wrong guess easily enough to make any sense of it, that's the property 
of a message digest.


But if it's a worry, rewrite it?

   int sum = 0;
   for (i = 0; i < digest.length; i++)
  sum += abs(digest[i] - hash[i]);

   return (0 == sum);


(Just thinking about it, not checking it at all...)

iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Digest comparison algorithm

2011-12-01 Thread Jerrie Union


Given the following Java code:

public boolean check(digest, secret) {  
   
  hash = md5(secret);   
  

  if (digest.length != hash.length)  {  
  
return false;   
  
  } 
  

  for (i = 0; i < digest.length; i++) { 
  
if (digest[i] != hash[i]) { 
  
  return false; 
  
}   
  
  }   


  return true;  
  
} 

I’m wondering, if it’s running as some authenticated server application, if 
it should be considered as resistant to time attacks nowadays. I’m aware that’s
not a good practice, but I’m not clear if I should consider it as exploitable 
over the
network (on both intranet and internet scenarios). 

I would like to run some tests, but I’m not sure if I should follow some 
specific
approach. Anyone has done some research recently?




___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [liberationtech] Crypto Advocacy TED Talk

2011-12-01 Thread Eugen Leitl

- Forwarded message from Gregory Maxwell  -

From: Gregory Maxwell 
Date: Thu, 1 Dec 2011 01:38:33 -0500
To: Jeffrey Burdges 
Cc: liberationt...@lists.stanford.edu
Subject: Re: [liberationtech] Crypto Advocacy TED Talk

On Thu, Dec 1, 2011 at 12:01 AM, Jeffrey Burdges  wrote:
[snip]
> Aside from arguing these point, there should be emphasis that "this ain't 
> your daddy's PGP", meaning modern crypto packages have grown incredibly easy 
> to use.  Tor Browser Bundles are about the most user friendly thing in the 
> world.  Off-the-record messaging is almost a triviality in Adium, Jitsi, or 
> other open source IM clients.  Most mail readers have user friendly plugins 
> for GPG.  etc.

I've argued before that protocol designers have an ethical obligation
to include always-on-by-default cryptography whenever it isn't
contraindicated by other requirements— The primary idea being here
that the whole cost of cryptography to the user can be drastically
reduced when its properly integrated.

In particular, even unauthenticated cryptography provides absolute
immunity to passive attacks, invisible wiretapping dragnets, and gives
active attacks a serious risk of discovery.  And this protection can
be added to any realtime communication for _free_ and invisibly from
the users perspective.  (Of course, authentication is important— and
nothing unauthenticated should be advertised to the user as encrypted.
But the unavoidable user-costlyness of authentication shouldn't
prevent us from getting encryption).

One point on this subject that is overlooked is the network effect: I
may have good reasons why I should be using encryption, but it's very
hard to use it when most of my friends are not using it.  This is
related to your point (1), but not identical. Unrelated to cover, my
contacts can't use encryption with me if I don't use encryption— and
asking me to use it is a social/time cost that discourages them from
using it when they really should. Unless encryption is a norm they
won't even ask.

Related to your point (2) I'd add a more subtle argument: The
widespread use of unencrypted communications enables an _industry_ of
dragnet surveillance.  Iran pays FooBarNetworks to build a fleet of
passive eavesdropping widgets... The R&D cost gets sunk building it
and then FooBar has a new product in their price book which their
sales drones go peddling to everyone who will take them, including the
governments of countries which are less prone to coming up with these
initiatives on their own. In this manner, oppression gains a marketing
department.  Fairly modest decreases in the effectiveness of
surveillance can break this cycle by making the initial cost less
appealing and making the products harder to sell.

(And at the extreme limit: A few billion to build and maintain an
infrastructure of hundreds of thousands of optical taps and fast
stateless packet filters is a _lot_ more attractive when it will
intercept Almost Everything then when its mostly only useful for
traffic analysis).

Another point that I make when discussing this subject is that none of
us is really able to correctly assess the risks in making the choice
to use encryption:  We're not aware of secret lawful and unlawful
interception by governments (our own, and/or hostile ones) and
organized crime. We don't have a good feel for how massive collections
of data may be used against our interests in the future. And once
disclosed the information genie can't easily be rebottled. Encryption
is cheap insurance, and would be much cheaper if ubiquitously
deployed.
___
liberationtech mailing list
liberationt...@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders.

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech
- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] InfoSec Southwest 2012 CFP

2011-12-01 Thread I)ruid

InfoSec Southwest 2012 Call for Papers
March 30th through April 1st 2012, Austin, Texas
http://infosecsouthwest.com/cfp.html

The InfoSec Southwest staff are now soliciting papers to be presented at
our 2012 conference to be held March 30th through April 1st 2012 in
Austin, Texas.

Who Should Submit

InfoSec Southwest is intended to be a general security and hacking
conference with no specific industry or topical focus. As such, nearly
all topics (other than vendor pitches) are fair game and the attending
audience is expected to span all demographics. Thus, we cordially invite
anyone who has a paper to present to submit for inclusion in the
conference.

Conference Format

InfoSec Southwest currently has two tracks slated for presentation. The
first track is intended for traditional, full-length presentations and
lectures. This is the track where lectures selected via the CFP process
will be presented. The second track is modeled after our local AHA!
(Austin Hackers Association) group's monthly meetings and is an open
forum for first-come, first-served lighting and turbo talks.

Please see the conference website's CFP page for our submission
procedure and speaker remuneration information:

http://infosecsouthwest.com/cfp.html

Important Dates

2011.12.01: Call for Papers Opens
2011.01.01: Preferential First Round Speaker Selection Announced and
Notifications Sent
2012.02.01: Call for Papers Deadline
2012.03.01: Final Speaker Selections Announced and Notifications Sent
2012.03.30: InfoSec Southwest 2012 Conference Registration and Reception
2012.03.31: InfoSec Southwest 2012 Conference Day 1
2012.04.01: InfoSec Southwest 2012 Conference Day 2

Thanks,

-- 
I)ruid, C²ISSP
dr...@caughq.org
http://druid.caughq.org


signature.asc
Description: This is a digitally signed message part
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors?

2011-12-01 Thread Harald Hanche-Olsen

[ianG  (2011-12-01 16:43:59 UTC)]

> I'm just poking around, it seems that Certificate Patrol should keep
> the cert.
> 
> In Firefox
> 
> Tools / Add-ons / Certificate Patrol / Preferences / View Certificates
> / getting tired now / [...] / ... time for a stiff drink [...]

As an alternative, you can just go and get them backstage. There is a
file CertPatrol.sqlite in your profile directory. You can point
sqlite3 at it and muck around with sql commands until you find the
cert you want. There is only one table of note in there, helpfully
named "certificates". The columns themselves have helpful names, with
the cert column being of type blob. So I guess a few lines of python
might be the easiest way to extract it.

- Harald
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

2011-12-01 Thread Ben Laurie

http://www.trustico.com/material/DS_GeoRoot_0205.pdf

Well, we'll only break the dishonest ones :-)

On Thu, Dec 1, 2011 at 5:48 PM, Marsh Ray  wrote:
> On 12/01/2011 11:09 AM, Ben Laurie wrote:
>>
>> On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray
>> wrote:


 http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html
>>
>>
>> They appear to actually be selling sub-RA functionality, but very
>> hard to tell from the press release.
>>
>> Bottom line: I'm going to believe this one someone displays a cert
>> chain.
>
>
>
> Translated:
>
>> GeoRoot is only available for internal use, and organizations must
>> meet certain eligibility requirements, [...]  compliance guidelines,
>> and hardware security specifications.
>
>      
>
>
>> Organizations must maintain a list Certificate Revocation List (CRL)
>
>  ^^
>
>
>> for all certificates issued by the company.
>
>                       
>
>
> But don't worry,  Mozilla has a "checklist" for sub-CAs!
>
> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>
>> Home » CA:SubordinateCA_checklist
>
>
>> Terminology
>>
>> The following terminology will be used in this wiki page regarding
>> subordinate CAs.
>>
>> Third-Party: The subordinate CA is operated by a third party external
>> to the root CA organization; and/or an external third party may
>> directly cause the issuance of a certificate within the CA
>> hierarchy.
>
>
>> Third-party private (or enterprise) subordinate CAs: This is the case
>> where a commercial CA has enterprise customers who want to operate
>> their own CAs for internal purposes, e.g., to issue SSL server
>> certificates to systems running intranet applications, to issue
>> individual SSL client certificates for employees or contractors for
>> use in authenticating to such applications, and so on.
>>
>> * These sub-CAs are not functioning as public CAs, so typical Mozilla
>> users would not encounter certificates issued by these sub-CAs in
>
>
> s/would/should/
>
>> their normal activities.
>> * For these sub-CAs we need assurance that
>> they are not going to start functioning as public CAs.
>
>
> As Dan would say, security comes from this "absence of the potential" for
> this type of surprise.
>
> This is not security, this reliance.
>
>> Currently the
>> only assurances available for this case it to ensure that these third
>> parties are required to follow practices that satisfy the Mozilla CA
>> Certificate Policy, and that these third parties are under an
>> acceptable audit regime.
>
>
> Promises, promises.
>
>> o In Bug #394919 NSS is being updated to
>> apply dNSName constraints to the CN, in addition to the SANs.
>> o We
>> plan to update our policy to require CAs to constrain third-party
>> private (or enterprise) subordinate CAs so they can only issue
>> certificates within a specified domain. See section 4.2.1.10 of RFC
>> 5280.
>
>
> Someday.
>
> To be fair to Mozilla, at least they're the ones with an open policy about
> it. I didn't find such a policy for the other popular web clients (I may not
> have looked hard enough).
>
> - Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)


On 12/01/2011 11:09 AM, Ben Laurie wrote:

On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray
wrote:

http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html


They appear to actually be selling sub-RA functionality, but very
hard to tell from the press release.

Bottom line: I'm going to believe this one someone displays a cert
chain.



Translated:


GeoRoot is only available for internal use, and organizations must
meet certain eligibility requirements, [...]  compliance guidelines,
and hardware security specifications.

  


Organizations must maintain a list Certificate Revocation List (CRL)

  ^^


for all certificates issued by the company.

   


But don't worry,  Mozilla has a "checklist" for sub-CAs!

https://wiki.mozilla.org/CA:SubordinateCA_checklist


Home » CA:SubordinateCA_checklist



Terminology

The following terminology will be used in this wiki page regarding
subordinate CAs.

Third-Party: The subordinate CA is operated by a third party external
to the root CA organization; and/or an external third party may
directly cause the issuance of a certificate within the CA
hierarchy.



Third-party private (or enterprise) subordinate CAs: This is the case
where a commercial CA has enterprise customers who want to operate
their own CAs for internal purposes, e.g., to issue SSL server
certificates to systems running intranet applications, to issue
individual SSL client certificates for employees or contractors for
use in authenticating to such applications, and so on.

* These sub-CAs are not functioning as public CAs, so typical Mozilla
users would not encounter certificates issued by these sub-CAs in


s/would/should/


their normal activities.
* For these sub-CAs we need assurance that
they are not going to start functioning as public CAs.


As Dan would say, security comes from this "absence of the potential" 
for this type of surprise.


This is not security, this reliance.


Currently the
only assurances available for this case it to ensure that these third
parties are required to follow practices that satisfy the Mozilla CA
Certificate Policy, and that these third parties are under an
acceptable audit regime.


Promises, promises.


o In Bug #394919 NSS is being updated to
apply dNSName constraints to the CN, in addition to the SANs.
o We
plan to update our policy to require CAs to constrain third-party
private (or enterprise) subordinate CAs so they can only issue
certificates within a specified domain. See section 4.2.1.10 of RFC
5280.


Someday.

To be fair to Mozilla, at least they're the ones with an open policy 
about it. I didn't find such a policy for the other popular web clients 
(I may not have looked hard enough).


- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

2011-12-01 Thread Paul Hoffman

On Dec 1, 2011, at 9:09 AM, Ben Laurie wrote:

> Bottom line: I'm going to believe this one someone displays a cert chain.

Multiple cert chains from different environments, please. One from Boingo (I'm 
not traveling for a few months so I can't grab one sooner), one from a 
corporation using a SonicWALL or similar box, and so on. We should not assume 
that all chains will have the same properties.

--Paul Hoffman

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

2011-12-01 Thread Ben Laurie

On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray  wrote:
> On 11/30/2011 06:44 PM, Adam Back wrote:
>>
>> Are there really any CAs which issue sub-CA for "deep packet
>> inspection" aka doing MitM and issue certs on the fly for everything
>> going through them: gmail, hotmail, online banking etc.
>
>
>
>>
>> http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html

They appear to actually be selling sub-RA functionality, but very hard
to tell from the press release.

Bottom line: I'm going to believe this one someone displays a cert chain.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)