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-05 Thread David Johnston

On 10/4/2013 10:23 AM, Phillip Hallam-Baker wrote:
On Fri, Oct 4, 2013 at 12:27 AM, David Johnston d...@deadhat.com 
mailto:d...@deadhat.com wrote:


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.


You mean Keccak is spongeworthy.

It may be, but that wasn't really my argument. My argument was that 
algorithm speed cannot have been the primary selection criteria because 
Keccak is not the fastest and faster alternatives had a similar or 
better security margin in the claims made.




I do not accept the argument that the computational work factor should 
be 'balanced' in the way suggested.


The security of a system is almost always better measured by looking 
at the work factor for breaking an individual message rather than the 
probability that two messages might be generated in circumstances that 
cancel each other out.


Given adequate cryptographic precautions (e.e. random serial), a 
certificate authority can still use MD5 with an acceptable level of 
security even with the current attacks. They would be blithering 
idiots to do so of course but Flame could have been prevented with 
certain precautions.


If a hash has a 256 bit output I know that I cannot use it in a 
database if the number of records approaches 2^128. But that isn't 
really a concern to me. The reason I use a 256 bit hash is because I 
want a significant safety margin on the pre-image work factor.


If I was really confident that the 2^128 work factor really is 2^128 
then I would be happy using a 128 bit hash for most designs. In fact 
in PRISM-Proof Email I am currently using a 226 bit Subject Key 
Identifier because I can encode that in BASE64 and the result is about 
the same length as a PGP fingerprint. But I really do want that 2^256 
work factor.


If Keccak was weakened in the manner proposed I would probably use the 
512 bit version instead and truncate.



I don't disagree, but it's a tad orthogonal to my argument.

--
Website: http://hallambaker.com/


___
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: RNG using AES CTR as encryption algorithm

2009-09-08 Thread David Johnston
NIST doesn't provide specific KAT vectors for AES-CTR because the 
results depend on your specific counter construction.
When you interact with a FIPS test lab, you will provide them with your 
counter construction, they will provide you with the KATs and you will 
then test to those KATs.


This is probably why you are not finding AES-CTR vectors in the same 
places you might find AES-CBC vectors. NIST explains this somewhere in 
their publications.


Convincing yourself that you have implemented AES-CTR correctly usually 
involves first checking that your AES-ECB is correct, then putting the 
output of you counter construction into some other known good AES-CTR 
implementation and comparing the results with your implementation.


Regards,
DJ

priya yelgar wrote:

Hi all,

I have implemented RNG using AES algorithm in CTR mode.

To test my implementation I needed some test vectors.

How ever I searched on the CSRC site, but found the test vectors for AES_CBC 
not for AES CTR.

Please  can any one tell me where to look for the test vectors to test RNG 
using  AES CTR.


Thanks in advance 
Priya Ainapur


  


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


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]