Re: [Cryptography] The paranoid approach to crypto-plumbing

[John Kelsey]

Arggh!  Of course, this superencryption wouldn't help against the CBC padding 
attacks, because the attacker would learn plaintext without bothering with the 
other layers of encryption.  The only way to solve that is to preprocess the 
plaintext in some way that takes the attacker's power to induce a timing 
difference or error message away.  

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

Re: [Cryptography] The paranoid approach to crypto-plumbing

[John Kelsey]

For hash functions, MACs, and signature schemes, simply concatenating 
hashes/MACs/signatures gives you at least the security of the stronger one.  
Joux multicollisions simply tell us that concatenating two or more hashes of 
the same size doesn't improve their resistance to brute force collsion search 
much.  The only thing you have to be sure of there is that the MAC and 
signature functions aren't allowed access to each others' secret keys or 
internal random numbers.  Otherwise, MAC#1 can always take the value of MAC#2's 
key.  This is just

message, signature 1, signature 2

where the signatures are over the message only.  

For encryption algorithms, superencryption works fine.  You can first encrypt 
with AES-CBC, then encrypt with Twofish-CFB, then with CAST5 in CFB mode.  
Again, assuming you are not letting the algorithms know each others' internal 
state or keys, if any of these algorithms are resistant to chosen plaintext 
attacks, then the combination will be.  This doesn't guarantee that the 
combination will be any stronger than the strongest of these, but it will be no 
weaker.  (Biham and later Wagner had some clever attacks against some chaining 
modes using single-DES that showed that you wouldn't always get anything 
stronger than one of the ciphers, but if any of these layers is strong, then 
the whole encryption is strong.  

An alternative approach is to construct a single super-block-cipher, say 
AES*Twofish*SERPENT, and use it in a standard chaining mode.  However, then you 
are still vulnerable to problems with your chaining mode--the CBC reaction 
attacks could still defeat a system that used AES*Twofish*SERPENT in CBC mode, 
but not AES-CBC followed by Twofish-CFB followed by SERPENT-CTR.  

For key-encryption or transport, I think it's a little more complicated.  If I 
need six symmetric keys and want to use three public key methods (say ECDH, 
NTRU, RSA) to transport the key, I've got to figure out a way to get the 
benefit from all these key exchange mechanisms to all six symmetric keys, in a 
way that I'm sure will not leak any information about any of them.  Normally we 
would use a KDF for this, but we don't want to trust any one crypto algorithm 
not to screw us over.  

I think we can get this if we assume that we can have multiple KDFs that have 
secrets from one another.  That is, I compute 

KDF1( key1, combined key exchange input) XOR KDF2( key2, combined key exchange 
input)

The reason the two KDFs need keys that are secret from each other is because 
otherwise, KDF1 could just duplicate KDF2 and we'd get an all-zero set of keys. 
 If KDF2 is strong, then KDF1 can't generate an output string with any 
relationship to KDF2's string when it doesn't know all the input KDF2 is 
getting.  

I agree with Perry that this is probably padlocking a screen door.  On the 
other hand, if we want to do it, we want to make sure we guard against as many 
bad things as possible.  In particular, it would be easy to do this in such a 
way that we missed chaining mode/reaction type attacks.  

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

Re: [Cryptography] FISA court releases its "Primary Order" re telephone metadata

[Alfie John]

On Wed, Sep 18, 2013, at 11:02 AM, John Gilmore wrote:
> That document is here:
> 
>   http://www.uscourts.gov/uscourts/courts/fisc/br13-09-primary-order.pdf

Page 4:

  "In granting the government's request, the Court has prohibited the
  government from accessing the data for any other intelligence or
  investigative purpose"

And the counter:

  
http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/05/the-nsa-is-giving-your-phone-records-to-the-dea-and-the-dea-is-covering-it-up/

Alfie

-- 
  Alfie John
  alf...@fastmail.fm
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

[Cryptography] FISA court releases its "Primary Order" re telephone metadata

[John Gilmore]

The FISA court has a web site (newly, this year):

  http://www.uscourts.gov/uscourts/courts/fisc/index.html

Today they released a "Memorandum Opinion and Primary Order" in 
case BR 13-109 ("Business Records, 2013, case 109"), which lays
out the legal reasoning behind ordering several telephone companies
to prospectively give NSA the calling records of every subscriber.
That document is here:

  http://www.uscourts.gov/uscourts/courts/fisc/br13-09-primary-order.pdf

I am still reading it...

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

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Bill Frantz]

On 9/17/13 at 4:18 PM, leich...@lrw.com (Jerry Leichter) wrote:

MAC'ing the actual data always seemed more "logical" to me, but 
once you look at the actual situation, it no longer seems like 
the right thing to do.


When I chose MAC then encrypt I was using the MAC to check the 
crypto code. CRC would have worked too, but the MAC was free. (I 
really don't trust my own code very much.)


Cheers - Bill

-
Bill Frantz| The first thing you need when  | Periwinkle
(408)356-8506  | using a perimeter defense is a | 16345 
Englewood Ave
www.pwpconsult.com | perimeter. | Los Gatos, 
CA 95032


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

Re: [Cryptography] An NSA mathematician shares his from-the-trenches view of the agency's surveillance activities

[John Gilmore]

Techdirt takes apart his statement here:

  
https://www.techdirt.com/articles/20130917/02391824549/nsa-needs-to-give-its-rank-and-file-new-talking-points-defending-surveillance-old-ones-are-stale.shtml

  NSA Needs To Give Its Rank-and-File New Talking Points Defending
  Surveillance; The Old Ones Are Stale
  from the that's-not-really-going-to-cut-it dept
  by Mike Masnick, Tue, Sep 17th 2013

  It would appear that the NSA's latest PR trick is to get out beyond
  the top brass -- James Clapper, Keith Alexander, Michael Hayden and
  Robert Litt haven't exactly been doing the NSA any favors on the PR
  front lately -- and get some commentary from "the rank and file."
  ZDNet apparently agreed to publish a piece from NSA mathemetician/
  cryptanalyst Roger Barkan in which he defends the NSA using a bunch
  of already debunked talking points. What's funny is that many of
  these were the talking points that the NSA first tried out back in
  June and were quickly shown to be untrue. However, let's take a
  look. It's not that Barkan is directly lying... it's just that he's
  setting up strawmen to knock down at a record pace.

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

Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

[Paul Crowley]

At a stretch, one can imagine circumstances in which trying multiple seeds
to choose a curve would lead to an attack that we would not easily
replicate. I don't suggest that this is really what happened; I'm just
trying to work out whether it's possible.

Suppose you can easily break an elliptic curve with the right "attack
string".  Attack strings are very expensive to generate, at say 2^80
operations. Moreover, you can't tell what curves they break until they are
generated, but it's cheap to test whether a given string breaks a given
curve. Each string breaks about one curve in 2^80. Thus the NSA generate an
attack string, then generate 2^80 curves looking for one that is broken by
the string they generated.  They can safely publish this curve, knowing
that unless a new attack is developed it will take 2^160 effort for anyone
else to generate an attack string that breaks the curve they have chosen.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

[Cryptography] Gilmore response to NSA mathematician's "make rules for NSA" appeal

[John Gilmore]

Re: http://www.zdnet.com/nsa-cryptanalyst-we-too-are-americans-720689/

In his Big Data argument, NSA analyst Roger Barkan carefully
skips over the question of what rules there should be for government
*collecting* big data, claiming that "what matters" are the rules for
how the data is used, *after* assuming that it will be collected.

Governments seldom lose powers; they work to grow their powers, to
loosen the rules that govern what they can do.  NSA's metadata
database has fewer restrictions today than it did when it was
collected, all carefully "legal" and vetted by a unaccountable
bureacracy that has its own best interests at heart.  My own Senator
Feinstein claims from her "oversight" post that whatever's good for
NSA is good for America; my Congresswoman Pelosi worked hard to defeat
the bill that would have stopped the NSA phone metadata program in
its tracks; and both of them run political machines that have made
them "lifetime" congresspeople, no matter how out-of-step they are
with their constituents.  NSA and these overseers conspired to keep
the whole thing secret, not to avoid "tipping off the terrorists" who
already knew NSA was lawless, but to avoid the public backlash that
would reduce their powers and maybe even reverse a decade of hugely
growing secret budgets.

Having watched the Drug War over the last 50 years, NSA for 30 years,
and TSA/DHS over the last decade, I have zero faith that NSA can
collect intimite data about every person in America and on the planet,
and then never use that data for any purpose that is counter to the
interest of the people surveilled.  There will always be
"emergencies", always "crises", always "evildoers", always
"opportunities", that would be relieved "if we could just do X that
wasn't allowed until now".  So what if general warrants are explicitly
forbidden?  And if searching people without cause is prohibited?  We
could catch two alleged terrorists -- or a few thousand people with
sexual images -- or 750,000 pot smokers -- or 400,000 hard-working
Mexican migrants -- every year, if we just use tricky legalisms to
ignore those pesky rules.  So the government does ignore them.  Will
you or your loved ones fall into the next witchhunt?  Our largest city
was just found guilty of forcibly stopping and physically searching
hundreds of thousands of black and latino people without cause for a
decade -- a racist program defended both before and after the verdict
by the Mayor, the Police Commission, the City Council, and state
legislators.  NSA has secretly been doing warrantless, suspicionless,
non-physical searches on every American with a phone for a decade, all
using secret gerrymandered catch-22 loopholes in the published
constitution and laws, defended before and after by the President, the
Congress and all the courts.  Make rules for NSA?  We already have
published rules for NSA and it doesn't follow them today!

So Mr Barkan moves on to why NSA would never work against the
citizens.  The US imprisons more people than any country on earth, and
murders far more than most, but it's all OK because those poor,
overworked, rule-bound government employees who are doing it are
"defending freedom".  Bullshit they are!  Somehow scores of countries
have found freedom without descending to this level of lawlessness and
repression.  NSA cannot operate outside of this context; rules that
might work in a hypothetical honest and free government, will not work
in the corrupt and lawless government that we have in the United
States.

NSA employees are accountable for following the rules, Mr. Barkan?
Don't make me laugh.  There's a word for it: impunity.  EFF has
diligently pursued NSA in court for most of a decade, and has still
gotten no court to even consider the question "is what NSA did legal?"
Other agencies like DoJ and HHS regularly retain big powers and
budgets by officially lying about whether marijuana has any medical
uses, rather than following the statutes, despite millions of
Americans who use it on the advice of their doctor.  None of these
officials lose their jobs.  Find me a senior federal official anywhere
who has ever lost their job over major malfeasance like wiretapping,
torture, kidnapping, indefinite imprisonment, assassination, or
malicious use of power -- let alone been prosecuted or imprisoned for
it.  Innocent citizens go to prison all the time, from neighborhood
blacks to medical marijuana gardeners to Tommy Chong and Martha
Stewart -- high officials never.

Re Big Data: I have never seen data that could be abused by someone
who didn't have a copy of it.  My first line of defense of privacy is
to deny copies of that data to those who would collect it and later
use it against me.  This is exactly the policy that NSA supposedly has
to follow, according to the published laws and Executive Orders: to
prevent abuses against Americans, don't collect against Americans.
It's a good first step.  NSA is not following that policy.

Where Big Data collec

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Dan McDonald]

On Sep 17, 2013, at 7:18 PM, Jerry Leichter wrote:

> On Sep 17, 2013, at 6:21 PM, John Kelsey  wrote:
>>> I confess I'm not sure what the current state of research is on MAC
>>> then Encrypt vs. Encrypt then MAC -- you may want to check on that.
>> 
>> Encrypt then MAC has a couple of big advantages centering around the idea 
>> that you don't have to worry about reaction attacks, where I send you a 
>> possibly malformed ciphertext and your response (error message, acceptance, 
>> or even time differences in when you send an error message) tells me 
>> something about your secret internal state.  
> On a purely practical level, to reject a damaged message, with 
> decrypt-then-MAC (ordering things on the receiver's side...) I have to pay 
> the cost of a decryption plus a MAC computation; with MAC-then-decrypt, I 
> only pay the cost of the MAC.  On top of this, decryption is often more 
> expensive than MAC computation.  So decrypt-then-MAC makes DOS attacks easier.
> 
> One could also imagine side-channel attacks triggered by chosen ciphertext.  
> Decrypt-then-MAC allows an attacker to trigger them; MAC-then-decrypt does 
> not. (Attacks on MAC's seems somewhat less likely to be data dependent, but 
> who knows for sure.  In any case, even if you had such an attack, it would 
> get you the authentication key - and at that point you would be able to 
> *start* your attack not the decryption key.

People have made these attacks mildly practical (and note how old this and the 
cited paper are).


http://kebesays.blogspot.com/2010/11/mac-then-encrypt-also-harmful-also-hard.html

Dan

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

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Jerry Leichter]

On Sep 17, 2013, at 6:21 PM, John Kelsey  wrote:
>> I confess I'm not sure what the current state of research is on MAC
>> then Encrypt vs. Encrypt then MAC -- you may want to check on that.
> 
> Encrypt then MAC has a couple of big advantages centering around the idea 
> that you don't have to worry about reaction attacks, where I send you a 
> possibly malformed ciphertext and your response (error message, acceptance, 
> or even time differences in when you send an error message) tells me 
> something about your secret internal state.  
On a purely practical level, to reject a damaged message, with decrypt-then-MAC 
(ordering things on the receiver's side...) I have to pay the cost of a 
decryption plus a MAC computation; with MAC-then-decrypt, I only pay the cost 
of the MAC.  On top of this, decryption is often more expensive than MAC 
computation.  So decrypt-then-MAC makes DOS attacks easier.

One could also imagine side-channel attacks triggered by chosen ciphertext.  
Decrypt-then-MAC allows an attacker to trigger them; MAC-then-decrypt does not. 
(Attacks on MAC's seems somewhat less likely to be data dependent, but who 
knows for sure.  In any case, even if you had such an attack, it would get you 
the authentication key - and at that point you would be able to *start* your 
attack not the decryption key.

MAC'ing the actual data always seemed more "logical" to me, but once you look 
at the actual situation, it no longer seems like the right thing to do.

-- Jerry

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

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Jerry Leichter]

On Sep 17, 2013, at 5:31 PM, Viktor Dukhovni  wrote:
> ...And indeed the FUD around the NIST EC curves is rather unfortunate.
> Is secp256r1 better or worse than 1024-bit EDH?
Given our state of knowledge both of the mathematics, and of games NSA has been 
playing, I don't believe anyone can give a meaningful answer to that question.  
There's a second, related question:  How are attacks on the two systems 
correlated?  If one falls, do we need to lower our estimate of the strength of 
the other?  In the case of an attack using a practical quantum computer, "very 
strongly correlated"; in the case of improvements along the lines of current 
integer factoring algorithms, "not very strongly correlated".  Over all, one 
has to make guesses.  I'd put them as "somewhat correlated".

-- Jerry

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

Re: [Cryptography] The paranoid approach to crypto-plumbing

[John Kelsey]

On Sep 17, 2013, at 11:41 AM, "Perry E. Metzger"  wrote:

> 
> I confess I'm not sure what the current state of research is on MAC
> then Encrypt vs. Encrypt then MAC -- you may want to check on that.

Encrypt then MAC has a couple of big advantages centering around the idea that 
you don't have to worry about reaction attacks, where I send you a possibly 
malformed ciphertext and your response (error message, acceptance, or even time 
differences in when you send an error message) tells me something about your 
secret internal state.  

> Perry

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

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Viktor Dukhovni]

On Tue, Sep 17, 2013 at 05:01:12PM -0400, Perry E. Metzger wrote:

> (Note that this assumes no cryptographic breakthroughs like doing
> discrete logs over prime fields easily or (completely theoretical
> since we don't really know how to do it) sabotage of the elliptic
> curve system in use.)
> 
> Given that many real organizations have hundreds of front end
> machines sharing RSA private keys, theft of RSA keys may very well be
> much easier in many cases than broader forms of sabotage.

There is also I suspect a lot of software with compiled-in EDH
primes (RFC 5114 or other).  Without breaking EDH generally, perhaps
they have better precomputation attacks that were effective against
the more popular groups.

I would certainly recommend that each server generate its own EDH
parameters, and change them from time to time.  Sadly when choosing
between a 1024-bit or a 2048-bit EDH prime you get one of
interoperability or best-practice security but not both.

And indeed the FUD around the NIST EC curves is rather unfortunate.
Is secp256r1 better or worse than 1024-bit EDH?

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

[Cryptography] An NSA mathematician shares his from-the-trenches view of the agency's surveillance activities

[John Gilmore]

Forwarded-By: David Farber 
Forwarded-By: "Annie I. Anton Ph.D." 

http://www.zdnet.com/nsa-cryptanalyst-we-too-are-americans-720689/

NSA cryptanalyst: We, too, are Americans

Summary: ZDNet Exclusive: An NSA mathematician shares his from-the-trenches 
view of the agency's surveillance activities.

By David Gewirtz for ZDNet Government | September 16, 2013 -- 12:07 GMT (05:07 
PDT)

An NSA mathematician, seeking to help shape the ongoing debate about the 
agency's foreign surveillance activities, has contributed this column to ZDNet 
Government. The author, Roger Barkan, also appeared in last year's National 
Geographic Channel special about the National Security Agency.

The rest of this article contains Roger's words only, edited simply for 
formatting.

Many voices -- from those in the White House to others at my local coffee shop 
-- have weighed in on NSA's surveillance programs, which have recently been 
disclosed by the media.

As someone deep in the trenches of NSA, where I work on a daily basis with data 
acquired from these programs, I, too, feel compelled to raise my voice. Do I, 
as an American, have any concerns about whether the NSA is illegally or 
surreptitiously targeting or tracking the communications of other Americans?

The answer is emphatically, "No."

NSA produces foreign intelligence for the benefit and defense of our nation. 
Analysts are not free to wander through all of NSA's collected data 
willy-nilly, snooping into any communication they please. Rather, analysts' 
activity is carefully monitored, recorded, and reviewed to ensure that every 
use of data serves a legitimate foreign intelligence purpose.

We're not watching you. We're the ones being watched.

Further, NSA's systems are built with several layers of checks and redundancy 
to ensure that data are not accessed by analysts outside of approved and 
monitored channels. When even the tiniest analyst error is detected, it is 
immediately and forthrightly addressed and reported internally and then to 
NSA's external overseers. Given the mountains of paperwork that the incident 
reporting process entails, you can be assured that those of us who design and 
operate these systems are extremely motivated to make sure that mistakes happen 
as rarely as possible!

A myth that truly bewilders me is the notion that the NSA could or would spend 
time looking into the communications of ordinary Americans. Even if such 
looking were not illegal or very dangerous to execute within our systems, given 
the monitoring of our activities, it would not in any way advance our mission. 
We have more than enough to keep track of -- people who are actively planning 
to do harm to American citizens and interests -- than to even consider spending 
time reading recipes that your mother emails you.

There's no doubt about it: We all live in a new world of Big Data.

Much of the focus of the public debate thus far has been on the amount of data 
that NSA has access to, which I feel misses the critical point. In today's 
digital society, the Big Data genie is out of the bottle. Every day, more 
personal data become available to individuals, corporations, and the 
government. What matters are the rules that govern how NSA uses this data, and 
the multiple oversight and compliance efforts that keep us consistent with 
those rules. I have not only seen but also experienced firsthand, on a daily 
basis, that these rules and the oversight and compliance practices are 
stringent. And they work to protect the privacy rights of all Americans.

Like President Obama, my Commander-in-Chief, I welcome increased public 
scrutiny of NSA's intelligence-gathering activities. The President has said 
that we can and will go further to publicize more information about NSA's 
operating principles and oversight methodologies. I have every confidence that 
when this is done, the American people will see what I have seen: that the NSA 
conducts its work with an uncompromising respect for the rules -- the laws, 
executive orders, and judicial orders under which we operate.

As this national dialogue continues, I look to the American people to reach a 
consensus on the desired scope of U.S. intelligence activities. If it is 
determined that the rules should be changed or updated, we at NSA would 
faithfully and effectively adapt. My NSA colleagues and I stand ready to 
continue to defend this nation using only the tools that we are authorized to 
use and in the specific ways that we are authorized to use them. We wouldn't 
want it any other way.

We never forget that we, too, are Americans.

Roger Barkan, a Harvard-trained mathematician, has worked as an NSA 
cryptanalyst since 2002. The views and opinions expressed herein are those of 
the author and do not necessarily reflect those of the National Security 
Agency/Central Security Service.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/ma

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Perry E. Metzger]

On Tue, 17 Sep 2013 16:52:26 -0400 John Kemp  wrote:
> On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker
>  wrote:
> > The objective of PRISM-hardening is not to prevent an
> > attack absolutely, it is to increase the work factor for the
> > attacker attempting ubiquitous surveillance.
> > 
> > Examples include:
> > 
> > Forward Secrecy: Increases work factor from one public key per
> > host to one public key per TLS session.
> 
> How does that work if one of PRISMs objectives is to compromise
> data _before_ it is transmitted by subverting its storage in one
> way or another?
> 
> Forward secrecy does nothing to impact the "work factor" in that
> case.

So, PFS stops attackers from breaking all communications by simply
stealing endpoint RSA keys. You need some sort of side channel or
reduction of the RNG output space in order break an individual
communication then.

(Note that this assumes no cryptographic breakthroughs like doing
discrete logs over prime fields easily or (completely theoretical
since we don't really know how to do it) sabotage of the elliptic
curve system in use.)

Given that many real organizations have hundreds of front end
machines sharing RSA private keys, theft of RSA keys may very well be
much easier in many cases than broader forms of sabotage.

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Bill Frantz]

On 9/17/13 at 2:48 AM, i...@iang.org (ianG) wrote:


The problem with adding multiple algorithms is that you are also adding 
complexity. ...


Both Perry and Ian point out:

And, as we know, the algorithms rarely fail. [but systems do] ...


Absolutely! The techniques I suggested used the simplest 
combining function I could think of: XOR. But complexity is the 
mortal enemy of reliability and security.




Do you really have the evidence that such extra effort is required?


I don't have any evidence, which is why I included Paranoid it 
the message subject. I do know that NSA is well served when 
people believe things about cryptography which aren't true. If 
you believe TLS is broken[1] then you might use something much 
weaker in its place. If you believe AES/RSA/ECDSA etc. are 
strong when they aren't you will continue to rely on them.



Remember, while you're building this extra capability, 
customers aren't being protected at all, and are less likely to 
be so in the future.


I see this a the crux of our problem as responsible crypto 
people. The systems we thought were working are broken. For both 
professional and political reasons we need to fix them quickly.


My morning paper includes the comic "Non Sequitur". Today's 
strip has one of the regular characters being visited by two NSA 
agents. This story is front and center in the public's 
attention. There is no better time to press for whatever 
disruptive changes may be needed.


What we need is working code we can get adopted. It can be 
prototype code with more complete versions to come later. But 
our best chance of adoption is now.



On 9/17/13 at 8:54 AM, pe...@piermont.com (Perry E. Metzger) wrote:


(Of course, if the endpoints are trusted hardware running a formally
verified capability operating system and you still have time on your
hands, hey, why not? Of course, when I posted a long message about
modern formal verification techniques and how they're now practical,
no one bit on the hook.)


And I happen to have one in my back pocket. :-)

Yes, CapROS[2] isn't proven, but it is mature enough to build 
Perry's household encryption box. (There are ports to both X86 
and ARM. Device drivers are outside the kernel. The IP stack 
works. You probably don't need much more.) Any code that works 
in CapROS will probably port easily to a proven capability OS.


[And yes Perry, I was very impressed by your arguments for 
program proving technology. It is a bit out of my area of 
expertise. But I have always thought that different ways of 
looking at programs can only help them be more reliable, and 
proving is a different way.]




All that said, even I feel the temptation for low performance
applications to do something like Bill Frantz suggests. It is in the
nature of people in our community to like playing with such things.
Just don't take them *too* seriously please.


Hay, I like playing in the crypto sandbox, and redundancy is a 
classic technique. I have seen questions about DH -- factoring 
and key sizes, and EC -- cooked curves. If you worry about these 
issues, and don't have a third alternative, combining them seems 
like a good idea.



[1] And TLS is big enough to share with the internet the 
characteristic that it can be two things. The internet is always 
up somewhere. Some parts of TLS are secure for certain uses. The 
internet is never all up. Some parts of TLS are seriously broken.


[2] 

---
Bill Frantz| Concurrency is hard. 12 out  | Periwinkle
(408)356-8506  | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |- Jeff Frantz | Los Gatos, 
CA 95032


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

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[John Kemp]

On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker  wrote:

> My phrase PRISM-Proofing seems to have created some interest in the press.
> 
> PRISM-Hardening might be more important, especially in the short term. The 
> objective of PRISM-hardening is not to prevent an attack absolutely, it is to 
> increase the work factor for the attacker attempting ubiquitous surveillance.
> 
> Examples include:
> 
> Forward Secrecy: Increases work factor from one public key per host to one 
> public key per TLS session.

How does that work if one of PRISMs objectives is to compromise data _before_ 
it is transmitted by subverting its storage in one way or another?

Forward secrecy does nothing to impact the "work factor" in that case.

> 
> Smart Cookies: Using cookies as authentication secrets and passing them as 
> plaintext bearer tokens is stupid. It means that all an attacker needs to do 
> is to compromise TLS once and they have the authentication secret. The HTTP 
> Session-ID draft I proposed a while back reduces the window of compromise to 
> the first attack.
> 
> 
> I am sure there are other ways to increase the work factor. 

I think that "increasing the work factor" would often result in switching the 
kind of "work" performed to that which is easier than breaking secrets 
directly. That may be good. Or it may not. "PRISM-Hardening" seems like a blunt 
instrument, or at least one which may only be considered worthwhile in a 
particular context (technical protection) and which ignores the wider context 
(in which such technical protections alone are insufficient against this 
particular adversary).  

- johnk
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> ___
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

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

[Cryptography] Johns Hopkins round table on NSA and Crypto

[Perry E. Metzger]

Matthew Green tweeted earlier today that Johns Hopkins will be hosting
a roundtable at 10am EDT tomorrow (Wednesday, September 18th) to
discuss the NSA crypto revelations.

Livestream will be at: https://connect.johnshopkins.edu/jhuisicrypto/ 

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

[Tony Arcieri]

On Tue, Sep 17, 2013 at 8:54 AM, Perry E. Metzger wrote:

> I'd like to note quite strongly that (with certain exceptions like
> RC4) the odds of wholesale failures in ciphers seem rather small
> compared to the odds of systems problems like bad random number
> generators, sabotaged accelerator hardware, stolen keys, etc., and a
> smart attacker goes for the points of weakness.


As a counterpoint to what I was saying earlier, here's a tool that's likely
focusing on the wrong problems:

https://keybase.io/triplesec/

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

[Cryptography] PRISM-Proofing and PRISM-Hardening

[Phillip Hallam-Baker]

My phrase PRISM-Proofing seems to have created some interest in the press.

PRISM-Hardening might be more important, especially in the short term. The
objective of PRISM-hardening is not to prevent an attack absolutely, it is
to increase the work factor for the attacker attempting ubiquitous
surveillance.

Examples include:

Forward Secrecy: Increases work factor from one public key per host to one
public key per TLS session.

Smart Cookies: Using cookies as authentication secrets and passing them as
plaintext bearer tokens is stupid. It means that all an attacker needs to
do is to compromise TLS once and they have the authentication secret. The
HTTP Session-ID draft I proposed a while back reduces the window of
compromise to the first attack.


I am sure there are other ways to increase the work factor.



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

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Stephan Neuhaus]

On 2013-09-17 07:37, Peter Gutmann wrote:
> Tony Arcieri  writes:
>> On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz  wrote:
>>> After Rijndael was selected as AES, someone suggested the really paranoid
>>> should super encrypt with all 5 finalests [...].
>>
>> I wish there was a term for this sort of design in encryption systems beyond
>> just "defense in depth". AFAICT there is not such a term.
>>
>> How about the Failsafe Principle? ;)
> 
> How about Stannomillinery?

I like Stannopilosery better, but the first half is a keeper.  Or,
perhaps a bit incongruously, Stannopsaffery.

Fun,

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

Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

[Perry E. Metzger]

On Tue, 17 Sep 2013 10:07:38 -0700 Tony Arcieri 
wrote:
> The NSA of course participated in active attacks too, but it seems
> their main MO was passive traffic collection.

That's not what I've gotten out of the most recent revelations. It
would seem that they've been evading rather than breaking the crypto:
putting back doors in protocols, stealing keys, encouraging weak
RNGs, adding flaws to hardware, etc. -- as well as doing active
attacks using stolen or broken CA keys.

I don't doubt that they archive everything they can forever, of
course.

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Perry E. Metzger]

On Mon, 16 Sep 2013 17:47:11 -0700 Bill Frantz
 wrote:
> Authentication is achieved by signing the entire exchange with 
> DSA.  --  Change the protocol to sign the exchange with both RSA 
> and DSA and send and check both signatures.

Remember to generate the nonce for DSA using a deterministic method.

> The current data exchange encryption uses SHA1 in HMAC mode and 
> 3DES in CBC mode with MAC then encrypt. The only saving grace is 
> that the first block of each message is the HMAC, which will 
> make the known plain text attacks on the protocol harder. -- I 
> would replace this protocol with one that encrypts twice and 
> MACs twice. Using one of the modes which encrypt and MAC in one 
> operation as the inner layer is very tempting with a different 
> cypher in counter mode and a HMAC as the outer layer.

I confess I'm not sure what the current state of research is on MAC
then Encrypt vs. Encrypt then MAC -- you may want to check on that.

Also, you may want to generate your IVs deterministically from a
block cipher in counter mode, and not actually send them on the wire
-- see earlier discussions for why that is good, but in addition to
assuring the IVs are unpredictable and do not repeat, it prevents a
bad actor from using the IV as a covert channel. (Some would argue
against using CBC mode entirely -- see Rogaway's paper on block
cipher modes.)

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] AES [was NSA and cryptanalysis]

[William Muriithi]

> >> Such a backdoor would be feasible.
> > It might be feasible in theory (and see the Illinois Malicious
> > Processor as an example) but I think it would be hard to pull off
> > well -- too hard to account for changes in future code, too hard to
> > avoid detection of what you've done.
> Not sure this is true. If instead of leaking via the RNG, you leak via
> the cryptographic libraries *and* the windows socket libraries, then
> while there are probably two different teams involved, there is only one
> manufacturer - Microsoft.
>
> Ok that would exclude non-windows systems, which in this world of BYOD
> means an increasing number of ios or android devices - but the odds of
> one end or the other of any given exchange being a MS platform are
> good.  Provided the cryptographic libraries are queried in a specific
> manner for tcp sequence numbers (which can be enforced) the winsock team
> never need know how those are generated, leaving just the cryptographic
> library holding both the input and output.
>
I think you are over estimating how entrenched Windows is. First, its not
widely used on server side. Most of the server side is Linux based so if
you are on android or IOS, there is high chance you are not using Windows
on both ends.

Then they also are not as dominant as they were in the 90s and early 2000s.
Apparently, if you consider mobile devices, they make 30% of the computers
out there. So, for this to work, it got to be done across vendors.
>
>
William
> >
> > On the other hand, we know from the press reports that several
> > hardware crypto accelerators have been either backdoored or
> > exploited. In those, leaking key material to observers in things like
> > IVs or choices of nonces might be quite feasible. Such devices are
> > built to be tamper resistant so no one will even notice if you add
> > features to try to conceal the "extra functionality" of the device.
> >
> > For the Intel chips, I suspect that if they've been gimmicked, it
> > will be more subtle, like a skew in the RNG that could be explained
> > away as a manufacturing or design error. That said, things like the
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

[Tony Arcieri]

On Tue, Sep 17, 2013 at 9:28 AM, Perry E. Metzger wrote:

> In any case, I would continue to suggest that the weakest point
> (except for RC4) is (probably) not going to be your symmetric cipher.
> It will be protocol flaws and implementation flaws. No point in
> making the barn out of titanium if you're not going to put a door on
> it.


If your threat is a patient eavesdropper (particularly one that obsessively
archives traffic like the NSA) then combining ciphers can give you long
term confidentiality even in the event one of your encryption primitives is
compromised.

The NSA of course participated in active attacks too, but it seems their
main MO was passive traffic collection.

But yes, endpoint security is weak, and an active attacker would probably
choose that approach over trying to break particular algorithms.

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

Re: [Cryptography] End to end

[Max Kington]

On 17 Sep 2013 15:47, "Christoph Gruber"  wrote:
>
> On 2013-09-16 Phillip Hallam-Baker  wrote:
> [snip]
>>
>> If people are sending email through the corporate email system then in
many cases the corporation has a need/right to see what they are
sending/receiving.
>
> [snip]
>
> Even if an organisation has a need/right to look into people's email, it
is necessary to protect the communication on transport and storage. Of
course a certain way of key recovery has to be in place.
>
> Just my 2 cents

I intend to reply in more detail to the draft there's lots of very
interesting work there.

The most common approach to ILM for email in highly regulated sectors I've
seen is to divorce the storage and transport mechanism and associated
security from the long term storage. In a corporate environment the message
is captured pre encryption and transmission and stored.

Whilst key escrow mechanisms do exist the risk is that what gets escrowed
isn't what was sent if you maliciously want to tunnel data (imagine not
being able to decrypt a message at the request of the SEC or FSA because
the key you were sent is wrong by the desktop app, or conversely having to
decrypt everything first to check). You have the added issue of having to
store all the associated keys and in 7 years (the typical retention period
over here for business now regarded as complete, let alone long running
contracts still in play) still have software to decrypt it.

Hence, store in the clear, keep safe at rest using today's archival
mechanism and when that starts to get dated move onto the next one
en-masse, for all your media not just emails.

Hence for the purposes of your RFC perhaps view that as a problem that
doesn't require detailed specification.

M

>
>> --
>> Website: http://hallambaker.com/
>>
>> ___
>> The cryptography mailing list
>> cryptography@metzdowd.com
>> http://www.metzdowd.com/mailman/listinfo/cryptography
>
>
> ___
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

[Cryptography] Ivan Ristić blog post on TLS best practices

[Perry E. Metzger]

Recommends phasing out RC4 among other things:

http://blog.ivanristic.com/2013/09/updated-best-practices-deprecate-rc4.html

-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Jerry Leichter]

On Sep 17, 2013, at 5:49 AM, ianG  wrote:
>> 
>> I wish there was a term for this sort of design in encryption systems
>> beyond just "defense in depth". AFAICT there is not such a term.
>> 
>> How about the Failsafe Principle? ;)
> 
> A good question.  In my work, I've generally modelled it such that the entire 
> system still works if one algorithm fails totally.  But I don't have a name 
> for that approach.
How about the X Property (Trust No One - with a different slant on "One")?

-- Jerry :-)

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

Re: [Cryptography] End to end

[Christoph Gruber]

On 2013-09-16 Phillip Hallam-Baker  wrote:
[snip]
> If people are sending email through the corporate email system then in many 
> cases the corporation has a need/right to see what they are sending/receiving.
[snip]

Even if an organisation has a need/right to look into people's email, it is 
necessary to protect the communication on transport and storage. Of course a 
certain way of key recovery has to be in place.

Just my 2 cents

> -- 
> Website: http://hallambaker.com/
> ___
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] AES [was NSA and cryptanalysis]

[Dave Howe]

On 16/09/2013 23:39, Perry E. Metzger wrote:
> On Mon, 16 Sep 2013 11:54:13 -1000 Tim Newsham
>  wrote:
>> - A backdoor that leaks cryptographic secrets
>>
>> consider for example applications using an intel chip with
>> hardware-assist for AES. You're feeding your AES keys
>> directly into the cpu. Any attacker controlling the cpu has
>> direct access and doesn't have to do any fancy pattern matching
>> to discover the keys. Now if that CPU had a way to export
>> some or all of the bits through some channel that would also
>> be passively observable, the attacker could pull off an offline
>> passive attack.
>>
>> What about RNG output? What if some bits were redundantly
>> encoded in some of the RNG output bits which where then
>> used directly for tcp initial sequence numbers?
>>
>> Such a backdoor would be feasible.
> It might be feasible in theory (and see the Illinois Malicious
> Processor as an example) but I think it would be hard to pull off
> well -- too hard to account for changes in future code, too hard to
> avoid detection of what you've done.
Not sure this is true. If instead of leaking via the RNG, you leak via
the cryptographic libraries *and* the windows socket libraries, then
while there are probably two different teams involved, there is only one
manufacturer - Microsoft.

Ok that would exclude non-windows systems, which in this world of BYOD
means an increasing number of ios or android devices - but the odds of
one end or the other of any given exchange being a MS platform are
good.  Provided the cryptographic libraries are queried in a specific
manner for tcp sequence numbers (which can be enforced) the winsock team
never need know how those are generated, leaving just the cryptographic
library holding both the input and output.



>
> On the other hand, we know from the press reports that several
> hardware crypto accelerators have been either backdoored or
> exploited. In those, leaking key material to observers in things like
> IVs or choices of nonces might be quite feasible. Such devices are
> built to be tamper resistant so no one will even notice if you add
> features to try to conceal the "extra functionality" of the device.
>
> For the Intel chips, I suspect that if they've been gimmicked, it
> will be more subtle, like a skew in the RNG that could be explained
> away as a manufacturing or design error. That said, things like the
> IMP do give one pause. And *that* said, if you're willing to go as
> far as what the IMP does, you no longer need to simply try to leak
> information via the RNG or other crypto hardware, you can do far far
> worse.
>
> (For those not familiar with the Illinois Malicious Processor:
> https://www.usenix.org/legacy/event/leet08/tech/full_papers/king/king_html/
> )
>
> Perry

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

Re: [Cryptography] Radioactive random numbers

[Perry E. Metzger]

Added c...@panix.com -- if you want to re-submit this (and maybe not
top post it) I will approve it...

Perry

On Tue, 17 Sep 2013 11:08:43 -0400 Carl Ellison  wrote:
> If you can examine your setup and determine all possible memory in
> the device, count that memory in bit-equivalents, and discover that
> the number of bits is small (e.g., <8), then you can apply Maurer's
> test:
> 
> ftp://ftp.inf.ethz.ch/pub/crypto/publications/Maurer92a.pdf
> 
> 
> Of course, if you're concerned that someone has slipped you a CPU
> chip with a PRNG replacing the RNG, you can't detect that without
> ripping the chip apart.
> 
> On 9/12/13 11:00 AM, "Perry E. Metzger"  wrote:
> 
> >On Wed, 11 Sep 2013 17:06:00 -0700 Tony Arcieri 
> >wrote:
> >> It seems like Intel's approach of using thermal noise is fairly
> >> sound. Is there any reason why it isn't more widely adopted?
> >
> >Actually, I think things like this mostly have been missing
> >because manufacturers didn't understand they were important. Even
> >the Raspberry Pi now has an SoC with a hardware RNG.
> >
> >In addition to getting CPU makers to always include such things,
> >however, a second vital problem is how to gain trust that such RNGs
> >are good -- both that a particular unit isn't subject to a hardware
> >defect and that the design wasn't sabotaged. That's harder to do.
> >
> >Perry
> >-- 
> >Perry E. Metzger pe...@piermont.com
> >___
> >The cryptography mailing list
> >cryptography@metzdowd.com
> >http://www.metzdowd.com/mailman/listinfo/cryptography
> 
> 



-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] The paranoid approach to crypto-plumbing

[ianG]

On 17/09/13 01:40 AM, Tony Arcieri wrote:

On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz mailto:fra...@pwpconsult.com>> wrote:

After Rijndael was selected as AES, someone suggested the really
paranoid should super encrypt with all 5 finalests in the
competition. Five level super encryption is probably overkill, but
two or three levels can offer some real advantages.


I wish there was a term for this sort of design in encryption systems
beyond just "defense in depth". AFAICT there is not such a term.

How about the Failsafe Principle? ;)




A good question.  In my work, I've generally modelled it such that the 
entire system still works if one algorithm fails totally.  But I don't 
have a name for that approach.




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

Re: [Cryptography] The paranoid approach to crypto-plumbing

[ianG]

Hi Bill,



On 17/09/13 01:20 AM, Bill Frantz wrote:


The idea is that when serious problems are discovered with one
algorithm, you don't have to scramble to replace the entire crypto
suite. The other algorithm will cover your tail while you make an
orderly upgrade to your system.

Obviously you want to chose algorithms which are likely to have
different failure modes -- which I why I suggest that RC4 (or an
extension thereof) might still be useful. The added safety also allows
you to experiment with less examined algorithms.




The problem with adding multiple algorithms is that you are also adding 
complexity.  While you are perhaps ensuring against the failure of one 
algorithm, you are also adding a cost of failure in the complexity of 
melding.


E.g., as an example, look at the current SSL search for a secure 
ciphersuite (and try explaining it to the sysadms).  As soon as you add 
an extra algorithm, others are tempted to add their vanity suites, the 
result is not better but worse.


And, as we know, the algorithms rarely fail.  The NSA specifically 
targets the cryptosystem, not the algorithms.  It also doesn't like 
well-constructed and well-implemented systems.  (So before getting too 
exotic with the internals, perhaps we should get the basics right.)


In contrast to the component duplication approach, I personally prefer 
the layering duplication approach (so does the NSA apparently).  That 
is, have a low-level cryptosystem that provides the base encryption and 
authentication properties, and over that, layer an authorisation layer 
that adds any additional properties if desired (such as superencryption).


One could then choose complementary algorithms at each layer.  Having 
said all that, any duplication is expensive.  Do you really have the 
evidence that such extra effort is required?  Remember, while you're 
building this extra capability, customers aren't being protected at all, 
and are less likely to be so in the future.




iang

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

[Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

[Perry E. Metzger]

On the "Paranoid Cryptoplumbing" discussion:

I'd like to note quite strongly that (with certain exceptions like
RC4) the odds of wholesale failures in ciphers seem rather small
compared to the odds of systems problems like bad random number
generators, sabotaged accelerator hardware, stolen keys, etc., and a
smart attacker goes for the points of weakness.

I'm not going to put my admin hat on and stop the discussion so long
as it remains relatively sane and technical, but for most purposes it
is probably just reinforcing a steel door in a paper wall.

(Of course, if the endpoints are trusted hardware running a formally
verified capability operating system and you still have time on your
hands, hey, why not? Of course, when I posted a long message about
modern formal verification techniques and how they're now practical,
no one bit on the hook.)

All that said, even I feel the temptation for low performance
applications to do something like Bill Frantz suggests. It is in the
nature of people in our community to like playing with such things.
Just don't take them *too* seriously please.

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Sandy Harris]

On Mon, Sep 16, 2013 at 12:44 PM, Bill Frantz  wrote:

> Symmetric encryption:
>
>   Two algorithms give security equal to the best of them. Three
>   protect against meet-in-the-middle attacks. Performing the
>   multiple encryption at the block level allows block cyphers to
>   be combined with stream cyphers. RC4 may have problems, but
>   adding it to the mix isn't very expensive.

A paper of mine on combining a stream cipher with a block
cipher: http://eprint.iacr.org/2008/473

AES-256 uses 14 rounds vs. 10 for AES-128, so it is about
40% slower. Given 256 bits of key and a stream cipher that
is 5x faster than AES, you can use AES-128 and have 128
bits to key the stream cipher. AES-128 plus whitening that
changes for every block (two 128-bit blocks of stream
cipher output) has roughly the same cost as AES-256.

There are several ways to reduce the cost and/or increase
the security from there; see the paper for details.

I am still working on this notion and will have a new and
much improved version of that paper sometime this year.
Anyone I know moderately well who wants to review it
can contact me off-list for the current draft.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] The paranoid approach to crypto-plumbing

[Peter Gutmann]

Tony Arcieri  writes:
>On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz  wrote:
>> After Rijndael was selected as AES, someone suggested the really paranoid
>> should super encrypt with all 5 finalests in the competition. Five level
>> super encryption is probably overkill, but two or three levels can offer
>> some real advantages.
>
>I wish there was a term for this sort of design in encryption systems beyond
>just "defense in depth". AFAICT there is not such a term.
>
>How about the Failsafe Principle? ;)

How about Stannomillinery?

Peter.


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

Re: [Cryptography] Radioactive random numbers

[Perry E. Metzger]

On Tue, 17 Sep 2013 11:35:34 -0400 "Perry E. Metzger"
 wrote:
> Added c...@panix.com -- if you want to re-submit this (and maybe not
> top post it) I will approve it...

Gah! Accidentally forwarded that to the whole list, apologies.

-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

[Perry E. Metzger]

On Tue, 17 Sep 2013 12:15:48 -0400 Jerry Leichter 
wrote:
> Actually, I think there is a potentially interesting issue here:
> RC4 is faster and requires significantly fewer resources than
> modern block ciphers.  As a result, people would really like to use
> it - and actually they *will* continue to use it even in the face
> of the known attacks (which, *so far*, are hardly fatal except in
> specialized settings).

If you are dealing with huge numbers of connections, you probably have
hardware and AES is plenty fast -- modern Intel hardware accelerates
it, too.

(If you really want a fast stream cipher, why not use ChaCha20 or
something else that is probably much better than RC4? I mean, if
you're going to propose changing it, as you do, it won't interoperate
anyway, so you can substitute something better.)

In any case, I would continue to suggest that the weakest point
(except for RC4) is (probably) not going to be your symmetric cipher.
It will be protocol flaws and implementation flaws. No point in
making the barn out of titanium if you're not going to put a door on
it.

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

[Jerry Leichter]

On Sep 17, 2013, at 11:54 AM, "Perry E. Metzger"  wrote:
> I'd like to note quite strongly that (with certain exceptions like
> RC4) the odds of wholesale failures in ciphers seem rather small
> compared to the odds of systems problems like bad random number
> generators, sabotaged accelerator hardware, stolen keys, etc., and a
> smart attacker goes for the points of weakness
Actually, I think there is a potentially interesting issue here:  RC4 is faster 
and requires significantly fewer resources than modern block ciphers.  As a 
result, people would really like to use it - and actually they *will* continue 
to use it even in the face of the known attacks (which, *so far*, are hardly 
fatal except in specialized settings).

So ... is there some simple way of combining RC4 with *something* that 
maintains the performance while retaining the speed?  How about two separate 
RC4's (with independent keys) XOR'ed together?  That would still be 
considerably faster than AES.

There appear to be two general classes of known attacks:

1.  The initial key setup doesn't produce enough randomness;
2.  There are long-term biases in the output bytes.

The first of these can be eliminated by using AES to generate values to 
scramble the internal state.  The second can be hidden by doing post-whitening, 
XOR'ing in a byte from AES in (say) counter mode.  If you use a given byte 64 
times, then use the next byte of the output, you pay 1/64 the cost of actually 
using AES in counter mode, but any bias in the output would have to play out 
over a 64-byte segment.  (Actually, if you use ideas from other stream ciphers, 
changing the whitening every 64 bytes probably isn't right - you want the 
attacker to have to guess where the changeovers take place.  There are many 
ways to do that.)

Of course, don't take any of the above and go build code.  It's just 
speculation and likely has serious problems.  I toss it out to illustrate the 
idea.  Whether it's actually worthwhile ... I doubt it, but it's worth thinking 
about.

-- Jerry


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

[Cryptography] Ars Technica on the Taiwanese National ID smart card break

[Perry E. Metzger]

Weeks after the informal announcement, the Taiwanese National ID
smartcard break is finally getting press. It is a great example of
a piece of "certified" crypto hardware that works poorly because
of bad random number generation.

Good explanation for your technical but not security oriented friends
in Ars Technica:

http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/

-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography