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

2011-12-01 Thread Rose, Greg

On 2011 Nov 30, at 22:28 , Jon Callas wrote:

 On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote:
 
 I run a wonderful Firefox extension called Certificate Patrol. It keeps a 
 local cache of certificates, and warns you if a certificate, CA, or public 
 key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to 
 my stockbroker's web site, the warnings started to appear. Then it was just 
 checking IP addresses and stuff.
 
 And I presume you didn't save the cert.
 
 Of course, we just need to have people look for these and then save them.

Yes. I regret that I had much bigger issues at the time than saving the cert. 
But, honestly, this is just the most recent time I've seen it... usually when 
traveling. I'm sure it won't be long before someone with more time and 
inclination than me will see another one.

sorry about that,
Greg.
___
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 ianG

On 2/12/11 03:26 AM, Rose, Greg wrote:

On 2011 Nov 30, at 22:28 , Jon Callas wrote:


On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote:


I run a wonderful Firefox extension called Certificate Patrol. It keeps a local 
cache of certificates, and warns you if a certificate, CA, or public key 
changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my 
stockbroker's web site, the warnings started to appear. Then it was just 
checking IP addresses and stuff.

And I presume you didn't save the cert.

Of course, we just need to have people look for these and then save them.

Yes. I regret that I had much bigger issues at the time than saving the cert.


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 / Certificate Patrol, maybe click around here coz it 
didn't show the certs first time / turn off Group by Root Key / click on 
Stored Since to order, maybe twice / check the date in the hotel / ... 
time for a stiff drink / click on the cert / View / Details / Export / :-o


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



iang, now about that drink...
___
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 Marsh Ray

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

On Thu, Dec 1, 2011 at 4:56 PM, Marsh Rayma...@extendedsubset.com
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?

2011-12-01 Thread Harald Hanche-Olsen
[ianG i...@iang.org (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


[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] Digest comparison algorithm

2011-12-01 Thread Jon Callas

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 Marsh Ray

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

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


[cryptography] Newbie Question

2011-12-01 Thread Randall Webmail
From: ianG i...@iang.org 

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] 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


Re: [cryptography] Digest comparison algorithm

2011-12-01 Thread Marsh Ray

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] Newbie Question

2011-12-01 Thread Peter Gutmann
Randall Webmail rv...@insightbb.com 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] Newbie Question

2011-12-01 Thread Jon Callas

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

 From: ianG i...@iang.org
 
 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] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

2011-12-01 Thread Peter Gutmann
Marsh Ray ma...@extendedsubset.com 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] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

2011-12-01 Thread Peter Gutmann
Ben Laurie b...@links.org 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] 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


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

2011-12-01 Thread Jon Callas
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 Marsh Ray

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