Re: [Cryptography] P=NP on TV

2013-10-07 Thread David Johnston

On 10/6/2013 12:17 PM, Salz, Rich wrote:


Last week, the American TV show Elementary (a TV who-done-it) was 
about the murder of two mathematicians who were working on proof of 
P=NP. The implications to crypto, and being able to crack into 
servers was covered. It was mostly accurate, up until the deux ex 
machine of the of the NSA hiding all the loose ends at the last 
minute. J  Fun and available at http://www.cbs.com/shows/elementary/video/




That gets to the heart of why I think P != NP.

We are led to believe that if it is shown that P = NP, we suddenly have 
a break for all sorts of algorithms.
So if P really does = NP, we can just assume P = NP and the breaks will 
make themselves evident. They do not. Hence P != NP.


Wheres my Field's Medal?

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Sha3

2013-10-04 Thread David Johnston

On 10/1/2013 2:34 AM, Ray Dillinger wrote:
What I don't understand here is why the process of selecting a 
standard algorithm for cryptographic primitives is so highly focused 
on speed. ~


What makes you think Keccak is faster than the alternatives that were 
not selected? My implementations suggest otherwise.

I thought the main motivation for selecting Keccak was Sponge good.

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG

2013-09-09 Thread David Johnston

On 9/8/2013 4:27 AM, Eugen Leitl wrote:

- Forwarded message from James A. Donald jam...@echeque.com -

Date: Sun, 08 Sep 2013 08:34:53 +1000
From: James A. Donald jam...@echeque.com
To: cryptogra...@randombit.net
Subject: Re: [cryptography] Random number generation influenced, HW RNG
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 
Thunderbird/17.0.8
Reply-To: jam...@echeque.com

On 2013-09-08 3:48 AM, David Johnston wrote:

Claiming the NSA colluded with intel to backdoor RdRand is also to
accuse me personally of having colluded with the NSA in producing a
subverted design. I did not.

Well, since you personally did this, would you care to explain the
very strange design decision to whiten the numbers on chip, and not
provide direct access to the raw unwhitened output.
#1 So that that state remains secret from things trying to discern that 
state for purposes of predicting past or future outputs of the DRBG.


#2 So that one thread cannot undermine a second thread by putting the 
DRNG into a broken mode. There is only one DRNG, not one per core or one 
per thread. Having one DRNG per thread would be one of the many 
preconditions necessary before this could be contemplated.


#3 Any method of access is going have to be documented and supported and 
maintained as a constant interface across many generations of chip. We 
don't throw that sort of thing into the PC architecture without a good 
reason.


 #4 Obviously there are debug modes to access raw entropy source 
output. The privilege required to access those modes is the same debug 
access necessary to undermine the security of the system. This only 
happens in very controlled circumstances.




A decision that even assuming the utmost virtue on the part of the
designers, leaves open the possibility of malfunctions going
undetected.

That's what BIST is for. It's a FIPS and SP800-90 requirement.


That is a question a great many people have asked, and we have not
received any answers.

Yes they have. I've answered this same question multiple times.


Access to the raw output would have made it possible to determine that
the random numbers were in fact generated by the physical process
described, since it is hard and would cost a lot of silicon to
simulate the various subtle offwhite characteristics of a well
described actual physical process.
Access to the raw output would have been a massive can of worms. The 
statistical properties of the entropy source are easy to model and easy 
to test online in hardware. They are described in the CRI paper if you 
want to read them. That's a necessary part of a good entropy source. If 
you can't build an effective online test in hardware then the entropy 
source is not fit for purpose.


DJ



___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: Can you keep a secret? This encrypted drive can...

2006-12-04 Thread David Johnston

Leichter, Jerry wrote:

| Jon Callas wrote:
|  
|  
|  Moreover, AES-256 is 20-ish percent slower than AES-128. 
| Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much

| data.
AES-256 has a 256-bit key but exactly the same 128-bit block as AES-128
(and AES-192, for that matter).

|   So when implemented in hardware, AES-256 is substantially faster.
| 
| AES-256 - 18.26 bits per round

| AES-128 - 12.8 bits per round
| 
| I imagine that this would matter when the implementation is in a hard disk or

| disk interface.
It would, if it were true.
-- Jerry
  
I stand corrected.. The source of my error was reading the rijndael 
spec, not the nist spec.


DJ

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


Re: Can you keep a secret? This encrypted drive can...

2006-12-03 Thread David Johnston

Jon Callas wrote:



Moreover, AES-256 is 20-ish percent slower than AES-128. 
Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as 
much data. So when implemented in hardware, AES-256 is substantially faster.


AES-256 - 18.26 bits per round
AES-128 - 12.8 bits per round

I imagine that this would matter when the implementation is in a hard 
disk or disk interface.






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


Re: ISO rejects WAPI (for now)

2006-03-16 Thread David Johnston

Joachim Strombergson wrote:


Aloha!

I don't know if you have seen this, but ISO rejected the WAPI standard 
proposal, opting instead for 802.11i/WPA2.


http://eet.com/news/design/business/showArticle.jhtml?articleID=181502994

How terrible, AES instead of the secret sauce-cipher. ,-)

WAPI is no longer secret sausce. It has been published in Chinese, 
including the formerly unpublished SMS4 block cipher.





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