Re: [cryptography] NIST and other organisations that set up standards in information security cryptography. (was: Doubts over necessity of SHA-3 cryptography standard)

2012-04-23 Thread David Adamson
On 4/22/12, Tanja Lange ta...@hyperelliptic.org wrote:
 In reply to the latest postings:

 Many submissions were faster than SHA-2 at the time of submission. Lots
 of people had fun speeding up SHA-2 -- so the competition has definitely
 led to a faster SHA-2.

 Also, check out
   http://bench.cr.yp.to/graph-sha3/long.png
 to see that on CPUs Blake is faster than SHA-2; for the bigger CPUs also
 skein is faster than SHA-2, so there are efficiency benefits of the new
 hash functions. Furthermore, whichever candidate is chosen as SHA-3 will
 have a bigger security margin than SHA-2.
   

SUPERCOP is one of my favorite web sites. Kudos to you and Dan for the
great job.
Indeed Blake and Skein are faster than SHA-2, but NOT SIGNIFICANTLY.

MD5 is SIGNIFICANTLY faster than SHA-2, and terribly broken. Several
other candidates (including CubeHash) are significantly faster than
SHA-2 and they were broken with attacks requesting 2^170, 2^200,
2^380, 2^480 hash evaluations.

So, on one hand we will have SHA-3 that is NOT significantly faster
than SHA-2, and on the other hand we have expert opinions like that of
Bart Preneel saying in his talk given at the Twelfth International
Conference on Information and Communications Security ICICS 2010:
Now, we have learned that an improved MD design should include the
following parts: Salt + Output transformation + Counter + Wide pipe.

That is my sole point in this thread: I expect this gained knowledge
to be used by other rivals of NIST, in order to endorse hash
standards that will be as safe as SHA-3, but SIGNIFICANTLY faster than
SHA-3.

Regards,
David Adamson Jr
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] NIST and other organisations that set up standards in information security cryptography. (was: Doubts over necessity of SHA-3 cryptography standard)

2012-04-23 Thread Steven Bellovin

On Apr 23, 2012, at 12:51 14PM, David Adamson wrote:

 On 4/23/12, Samuel Neves sne...@dei.uc.pt wrote:
 
 On big hardware, the fastest SHA-3 candidates (BLAKE, Skein) are very
 much closer to MD5 in performance (~5.5 cpb) than SHA-2. Plus, I don't
 see any platform where CubeHash16/32 wins over either of them in speed.
 
 The place where SHA-2 shines is the very low end. Performance there,
 however, is usually measured in gates, not cpb.
 
 
 The latest performance of Skein and BLAKE that you are mentioning is
 due the continuous efforts of designers and independent programmers to
 improve their implementation. As I can see, measurements of SHA-2 are
 mostly from an OpenSSL implementation that is not as much optimized as
 the implementations of the 5 SHA-3 finalists. But once SHA-2 is
 started to be as aggressively optimized as SHA-3 finalists, we will
 see reports like the one in [1]: Furthermore, even the fastest
 finalists will probably  offer only a small performance advantage over
 the current SHA-256 and SHA-512 implementations.
 
 Unfortunately, also I do not see any more improvements of the
 implementations of other SHA-3 candidates that did not enter 2-nd and
 final round (especially CubeHash, Shabal, BMW, Edon-R, Echo and SIMD).
 
And the MD6 team withdrew their submission because they couldn't make
it fast enough and still have enough security.


--Steve Bellovin, https://www.cs.columbia.edu/~smb





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


Re: [cryptography] NIST and other organisations that set up standards in information security cryptography.

2012-04-23 Thread Marsh Ray

On 04/23/2012 01:53 PM, David Adamson wrote:


Ahhh, I think it was a mistake to withdraw MD6. But Ron and his team
had dignity and set up higher mathematical standards than NIST (the
hash function to be provably secure against the differential
cryptanalysis).


If you know of actual weaknesses in NIST's cryptanalysis or attacks on
any of the finalists now is the time to let them know.

http://lists.randombit.net/pipermail/cryptography/2012-March/002690.html
NIST requested community feedback before June 1, 2012 so that it can
be considered in the SHA-3 selection process. Feedback received after
the deadline, unless of very significant nature, may not impact the
final selection.


If you void the mathematically set up security margin of MD6 and
reduce the number of rounds from 168 down to 64, (with similar
artistic, cryptographer's experience and trust me arguments present
in other finalists) you will have a hash function that is faster than
SHA-2 and is definitively faster than 2 or 3 of the SHA-3 finalists


You're free to use such a function in your own protocols, but I doubt 
you'll find many other folks wanting to use it.



(I never understood why NIST picked up those 2 or 3 slower than SHA-2
candidates as finalists).


You might find this interesting:


http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/documents/Round2_Report_NISTIR_7764.pdf

The announcement of the five SHA-3 finalists – BLAKE, Grøstl, JH,
Keccak and Skein marked the end of the second round of the SHA-3
competition. This report summarizes the evaluation criteria, the
selection process, the designs of the second-round candidates and the
published security and performance results for each.

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


Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years

2012-04-23 Thread Peter Maxwell
On 23 April 2012 22:41, Marsh Ray ma...@extendedsubset.com wrote:


 Thought the list might be interested in this little development in the PKI
 saga.

 Do you all agree with my assertion that No one with a clue about PKI
 security would believe that a revoked cert provides equivalent security
 from misuse as a naturally-expired cert. ?

  - Marsh


With current client implementations, I agree your statement does hold.  I
do however disagree with your general premise that six years is too long.


Say two companies, A and B, have adopted similar security practices and
assume the probability of a cert compromise in a given year for one of them
is roughly one in ten thousand, p_yr = 0.0001

Company A has their cert issued with a two year validity, so their
probability of compromise is p_2yr = 1 - ( 0. ) ^ 2 ~= 2.10^-4

Company B has their cert issued with a six year validity, so their
probability of compromise is p_6yr = 1 - ( 0. ) ^ 6 ~= 6.10^-4


In other words, it makes not a jot of difference to company B: they may be
roughly three times more at risk than company A but that's still only a six
in ten thousand chance, say.  Even if the original p_yr were higher, say
one in a thousand, it still doesn't merit any concern for the individual
company.


If we then turn our attention to the system as a whole: assuming we look at
all certificates, does extending the expiry period help reduce the impact
on users?  Well, actually, counter-intuitively it does not.

The rationale is as follows...

i. assume at any given time, some rate of compromise of all available
issued certs, r;

ii. assume also that most certificate forgery is to steel money or commit
fraud, so there is an incentive to act quickly and the outlier cases of
long-term attacks can be discounted for now;

iii. further assume that the maximum time of utility for the attackers to
use the cert in ii. is approximately a day.

It immediately follows that for a whole-system expiry period of two years
the attacker is impeded and r is reduced by roughly 1 / ( 2 . 365 ) =
0.13%. For expiry times of six years that changes to a reduction of 1 / ( 6
. 365 ) = 0.05%.

That's a fairly marginal result and if we assume the attacker(s) know(s)
this, they will simply avoid tackling certs near expiry, rendering the
difference null.


So does the expiry period actually matter that much?  Intuitively yes,
rationally, no.


Regards,

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