Re: [Cryptography] [cryptography] RSA equivalent key length/strength

2013-09-19 Thread Joachim Strömbergson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Aloha!

Lucky Green wrote:
 Moti Young and others wrote a book back in the 90's (or perhaps)
 80's, that detailed the strength of various RSA key lengths over
 time. I am too lazy to look up the reference or locate the book on my
 bookshelf. Moti: help me out here? :-)

Can't help out with that. But I think that the ECRYPY Yearly Reports on
keylengths and algorithms are a great source for these kinds of
questions. The latest (from 2012) can be found here:

http://www.ecrypt.eu.org/documents/D.SPA.20.pdf

Unfortunately ECRYPY II has come to an end and I'm not certain the
report will be updated anymore. Would be a loss since having updated
estimates on keys and what algorithms to use is really helpful (IMHO).

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlI6onIACgkQZoPr8HT30QGuSgCgq31OzxzE5u931sIpY/XMs5Ry
dwAAniAkW7jGfLnakNqGnjhhm37vfELm
=Iqvv
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] RSA equivalent key length/strength

2013-09-19 Thread Phillip Hallam-Baker
On Wed, Sep 18, 2013 at 5:23 PM, Lucky Green shamr...@cypherpunks.towrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 2013-09-14 08:53, Peter Fairbrother wrote:

  I get that 1024 bits is about on the edge, about equivalent to 80
  bits or a little less, and may be crackable either now or sometime
  soon.

 Moti Young and others wrote a book back in the 90's (or perhaps) 80's,
 that detailed the strength of various RSA key lengths over time. I am
 too lazy to look up the reference or locate the book on my bookshelf.
 Moti: help me out here? :-)

 According to published reports that I saw, NSA/DoD pays $250M (per
 year?) to backdoor cryptographic implementations. I have knowledge of
 only one such effort. That effort involved DoD/NSA paying $10M to a
 leading cryptographic library provider to both implement and set as
 the default the obviously backdoored Dual_EC_DRBG as the default RNG.

 This was $10M wasted. While this vendor may have had a dominating
 position in the market place before certain patents expired, by the
 time DoD/NSA paid the $10M, few customers used that vendor's
 cryptographic libraries.

 There is no reason to believe that the $250M per year that I have seen
 quoted as used to backdoor commercial cryptographic software is spent
 to any meaningful effect.


The most corrosive thing about the whole affair is the distrust it has sewn.

I know a lot of ex-NSA folk and none of them has ever once asked me to drop
a backdoor. And I have worked very closely with a lot of government
agencies.


Your model is probably wrong. Rather than going out to a certain crypto
vendor and asking them to drop a backdoor, I think they choose the vendor
on the basis that they have a disposition to a certain approach and then
they point out that given that they have a whole crypto suite based on EC
wouldn't it be cool to have an EC based random number generator.

I think that the same happens in IETF. I don't think it very likely Randy
Bush was bought off by the NSA when he blocked deployment of DNSSEC for ten
years by killing OPT-IN. But I suspect that a bunch of folk were whispering
in his ear that he needed to be strong and resist what was obviously a
blatant attempt at commercial sabotage etc. etc.


I certainly think that the NSA is behind the attempt to keep the Internet
under US control via ICANN which is to all intents a quango controlled by
the US government. For example, ensuring that the US has the ability to
impose a digital blockade by dropping a country code TLD out of the root.
Right now that is a feeble threat because ICANN would be over in a minute
if they tried. But deployment of DNSSEC will give them the power to do that
and make it stick (and no, the key share holders cannot override the veto,
the shares don't work without the key hardware).

A while back I proposed a scheme based on a quorum signing proposal that
would give countries like China and Brazil the ability to assure themselves
that they were not subjected to the threat of future US capture. I have
also proposed that countries have a block of IPv6 and BGP-AS space assigned
as a 'Sovereign Reserve'. Each country would get a /32 which is more than
enough to allow them to ensure that an artificial shortage of IPv6
addresses can't be used as a blockade. If there are government folk reading
this list who are interested I can show them how to do it without waiting
on permission from anyone.


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

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

2013-09-19 Thread Salz, Rich
 I know I would be a lot more comfortable with a way to check the mail against 
 a piece of paper I received directly from my bank.

I would say this puts you in the sub 1% of the populace.  Most people want to 
do things online because it is much easier and gets rid of paper.  Those are 
the systems we need to secure.  Perhaps another way to look at it:  how can we 
make out-of-band verification simpler?

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


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

2013-09-19 Thread Robin Alden
 On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote:
  On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:
This is only realistic with DANE TLSA (certificate usage 2 or 3),
and thus will start to be realistic for SMTP next year (provided
DNSSEC gets off the ground) with the release of Postfix 2.11, and
with luck also a DANE-capable Exim release.
  
   What's wrong with name-constrained intermediates?
 
  X.509 name constraints (critical extensions in general) typically
  don't work.

Which is why the CAB Forum and Mozilla made the pragmatic move to promote
the use of X.509 name constraints as a non-critical extension.

 
 And public CAs don't generally sell intermediate CAs with name
constraints.
 Rather undercuts their business model.
 

Public CAs are starting to offer name-constrained intermediate CAs to
suitable customers.
Why wouldn't we? - It doesn't undercut our business model any more than
selling a wildcard certificate.

 --
   Viktor.

Robin Alden
Comodo

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


Re: [Cryptography] A lot to learn from Business Records FISA NSA Review

2013-09-19 Thread Ray Dillinger

On 09/16/2013 07:58 AM, Perry E. Metzger wrote:


Well, we do know they created things like the (not very usable)
seLinux MAC (Multilevel Access Control) system, so clearly they do
some hacking on security infrastructure.


SeLinux seems to be targeted mostly at organizational security,
whereas the primary need these days is not organizational, but
uniform.

That is to say, we don't in practice see many situations where
different levels and departments of an organization have complex
and different rules for how and whether they can access each
other's information and complex requirements for audit trails.

What we see is simpler; we see systems used by people who have
more or less uniform requirements and don't much need routine
auditing, except for one or two administrators.

More useful than the complexity of SeLinux would be a relatively
simple system in which ordinary Unix file permissions were
cryptographically enforced.  If for example read permissions on
a file are exclusive to some user or some group, then that file
should be encrypted so that no one else, even if the bytes are
accessible to them by some means, should be able to make sense
of it, and the configuration options should include not storing
the key to it anywhere in the system -- let the user plug a
USB stick in to give the key for his session, and let the user
remove it to take that key away again whenever he's not using it,
rather than leave it around on the hard drive somewhere potentially
to be accessed by someone else at some other time.

We have spent years learning to protect the operating system from
damage by casual mistakes and even from most actual attacks,
because for years control of the computer itself was the only
notable asset that needed to be protected.  It is still true that
control of the computer is always at least as valuable as
everything else that it could be used to compromise, but with
unencrypted files it can compromise far too much.  And the value
of what is stored in individual accounts has gotten far too high
to *NOT* give protecting them at least as much thought as
protecting root's access rights. Photographs, banking records,
schedules, archived mail going back for years, browser histories,
wallets that contain many other keys, etc, etc.  This is far
different from old days when what was on a user's account
was basically a few programs the user used and some text or
code that the user had written.  We need to catch up.

Bear

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


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

2013-09-19 Thread ianG

Hi John,

(I think we are in agreement here, there was just one point below where 
I didn't make myself clear.)



On 18/09/13 23:45 PM, John Kemp wrote:

On Sep 18, 2013, at 4:05 AM, ianG i...@iang.org wrote:


On 17/09/13 23:52 PM, John Kemp wrote:

On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker hal...@gmail.com



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.



Yes, that's the logical consequence  approach to managing risks. Mitigate the 
attack, to push attention to easier and less costly attacks, and then start working 
on those.

There is a mindset in cryptography circles that we eliminate entirely the 
attacks we can, and ignore the rest.  This is unfortunately not how the real 
world works.  Most of risk management outside cryptography is about reducing 
risks not eliminating them, and managing the interplay between those reduced 
risks.  Most unfortunate, because it leads cryptographers to strange 
recommendations.


The technical work always needs doing. It's not that we shouldn't do our best 
to improve cryptographic protection. It's more that one can always bypass 
cryptographic protection by getting to the cleartext before it is encrypted.



Right.  So the amount of effort we should put in should not be dictated 
(solely) by received wisdom about perfect security, but (also) by how 
quickly we can push the bulk of the attackers elsewhere.  Thus releasing 
our costly resources for 'elsewhere'.


I wrote about this tradeoff many moons ago.  I called the preferred 
target Pareto-secure as a counterpoint to the expected 100% secure, 
which I defined as a point where there is no Pareto-improvement that can 
be made, because the attacker is already pushed elsewhere.


The other side of the coin is to have a gentler attitude to breaches.

When a breach is announced, we also need to consider whether anyone has 
actually lost anything, and whether the ones that weren't attacked have 
got good service.  A protocol is rarely broken for the user, even if the 
cryptographic world uses the word 'broken' for a few bits.  E.g., if one 
looks at the TLS changes of the last 5 years due to a series of attacks, 
there isn't much of a record of actual hacks to users.




That may be good. Or it may not.



If other attacks are more costly to defender and easyish for the attacker, then 
perhaps it is bad.  But it isn't really a common approach in our security world 
to leave open the easiest attack, as the best alternative.  Granted, this 
approach is used elsewhere (in warfare for example, minefields and wire will be 
laid to channel the attack).

If we can push an attacker from mass passive surveillance to targetted direct 
attacks, that is a huge win.  The former scales, the latter does not.


My point was that mass passive surveillance is possible with or without 
breaking SSL/TLS (for example, but also other technical attacks), and that it is often 
simpler to pay someone to create a backdoor in an otherwise well-secured system. Or to 
simply pay someone to acquire the data in cleartext form prior to the employment of any 
technical protections to those data. Other kinds of technical protections (not really 
discussed here so far) might be employed to protect data from such attacks, but they 
would still depend on the possibility for an attacker to acquire the cleartext before 
such protections were applied.



To some extent, mass passive surveillance is entirely possible because 
SSL/TLS is so poorly employed.  I haven't looked for a while, but it was 
always about 1% of web traffic.


This is the motive behind HTTPS Everywhere - All The Time.  Let's make 
SSL the norm not the exception.  Then we've got some security against 
passive surveillance, then we force the attacker to other attacks, which 
are typically much more expensive.



I would point out that it was historically the case that the best espionage was achieved 
by paying (or blackmailing) people close to the source of the information to retrieve the 
necessary information. The idea of the mole. That would seem to still be 
possible.





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).



If I understand it correctly, PRISM is or has become the byword for the NSA's 
vacuuming of all traffic for mass passive surveillance.  In which case, this is 
the first attack of all, and the most damaging, because it is undetectable, 
connects you to all your contacts, and stores all your open documents.

 From the position of a systems provider, mass surveillance is possibly the 
most important attack to mitigate.


If you yourself the systems provider, 

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

2013-09-19 Thread Bill Frantz

On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote:


I know I would be a lot more comfortable with a way to check the mail against a 
piece of paper I

received directly from my bank.

I would say this puts you in the sub 1% of the populace.  Most 
people want to do things online because it is much easier and 
gets rid of paper.  Those are the systems we need to secure.  
Perhaps another way to look at it:  how can we make out-of-band 
verification simpler?


Do you have any evidence to support this contention? Remember 
we're talking about money, not just social networks.


I can support mine. ;-)

If organizations like Consumers Union say that you should take 
that number from the bank paperwork you got when you signed up 
for an account, or signed up for online banking, or got with 
your monthly statement, or got as a special security mailing and 
enter it into your email client, I suspect a reasonable 
percentage of people would do it. It is, after all a one time operation.


Cheers - Bill

---
Bill Frantz| If the site is supported by  | Periwinkle
(408)356-8506  | ads, you are the product.| 16345 
Englewood Ave
www.pwpconsult.com |  | Los Gatos, 
CA 95032


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


[Cryptography] Cryptographic mailto: URI

2013-09-19 Thread Phillip Hallam-Baker
I am in mid design here but I think I might have something of interest.

Let us say I want to send an email to al...@example.com securely.

Now obviously (to me anyway) we can't teach more than a small fraction of
the net to use any identifier other than the traditional email address.

So we need some sort of directory infrastructure to allow discovery of
those email addresses and it would be good to be able to reuse existing
directories if at all possible.


But how do we insert the email addresses into a directory like LinkedIn?
Well you can add a URI into your account. So what if the URI is of the form:

ppid:al...@example.com:example.net:
Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM

Where

al...@example.com is Alice's email address for secure communications

example.net is a server which will resolve the reference by means of a
simple HTTP query using the pattern http://host/.well-known/ppid/hash

Syd...NWM is the Base64 hash of OID-SHA256 + SHA256(X)

X is a public key that signs a document (probably JSON) that specifies:

* X
* Alice's certificate(s)
* Alice's email receipt policy whether to always encrypt, what message
formats are supported
* links to whatever additional advice information might help convince a
relying party the key is genuine like a CT log.
* reliance policy (is this key for public use or restricted)
* reporting policy (for future changes)

So to use this as a mechanism for ghetto key distribution receivers would
add the URI into their account. Or let their PKI discovery agent do it for
them.


Senders would enable their PKI discovery agent to access their LinkedIn
account.

It would slurp down the data once a day (say) and keep it in a cache for
use by that user alone unless it is marked public when any user of the PKI
discovery agent can make use of it.

It would attempt to validate the information obtained, possibly resulting
in a report if it detected a change in a previously registered key that had
not been properly countersigned by the old.

The validated info would then be used to encrypt the outbound mail
according to the specified policy.


Notes:

1) This is only about key discovery, not validation.

2) Better to send email encrypted under a key that is not validated than in
the clear.

3) A MUA should offer the option 'force encryption' however. And in that
case it would barf if the key provided didn't meet the validation criteria.


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

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

2013-09-19 Thread Peter Gutmann
Phillip Hallam-Baker hal...@gmail.com writes:

I have not spent a great deal of time looking at the exact capabilities of
PRISM vs the other programs involved because from a design point they are
irrelevant. The objective is to harden/protect the infrastructure from any
ubiquitous, indiscriminate intercept capability like the one Gen Alexander
appears to have constructed.

Precisely.  I made the same point recently in an interview about PRISM, that a
well-designed, well-engineered protocol will be NSA-proof (or at least as NSA-
proof as you can get within reason).  It'll also be Russian mafia-proof,
Chinese-government-proof, and your-mother-proof.  There isn't some exotic
class of protocol or mechanism that's needed to resist the NSA, anything well-
designed and implemented can do it.

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


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

2013-09-19 Thread Carl Wallace
On 9/18/13 5:50 PM, Viktor Dukhovni cryptogra...@dukhovni.org wrote:

On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote:

 On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:
 
   This is only realistic with DANE TLSA (certificate usage 2 or 3),
   and thus will start to be realistic for SMTP next year (provided
   DNSSEC gets off the ground) with the release of Postfix 2.11, and
   with luck also a DANE-capable Exim release.
  
  What's wrong with name-constrained intermediates?
 
 X.509 name constraints (critical extensions in general) typically
 don't work.

And public CAs don't generally sell intermediate CAs with name
constraints.  Rather undercuts their business model.

The inability to constrain trust anchors doesn't help matters much either.


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


Re: [Cryptography] The Case for Formal Verification

2013-09-19 Thread Derek Jones
Perry E. Metzger perry at piermont.com writes:

 CompCert is a fine counterexample, a formally verified C compiler:
 http://compcert.inria.fr/
 It works by having a formal spec for C, and a formal spec for the
 machine language output. The theorem they prove is that the

The claim of CompCert being a formally verified C compiler is wildly overstated:
http://shape-of-code.coding-guidelines.com/2013/03/10/verified-compilers-and-soap-powder-advertising/

It is a good start, but they still have lots of work to do.

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


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

2013-09-19 Thread Max Kington
On 19 Sep 2013 19:11, Bill Frantz fra...@pwpconsult.com wrote:

 On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote:

 I know I would be a lot more comfortable with a way to check the mail
against a piece of paper I

 received directly from my bank.

 I would say this puts you in the sub 1% of the populace.  Most people
want to do things online because it is much easier and gets rid of paper.
 Those are the systems we need to secure.  Perhaps another way to look at
it:  how can we make out-of-band verification simpler?


 Do you have any evidence to support this contention? Remember we're
talking about money, not just social networks.

 I can support mine. ;-)

 If organizations like Consumers Union say that you should take that
number from the bank paperwork you got when you signed up for an account,
or signed up for online banking, or got with your monthly statement, or got
as a special security mailing and enter it into your email client, I
suspect a reasonable percentage of people would do it. It is, after all a
one time operation.

As with other themes though, one size does not fit all. The funny thing
being that banks are actually extremely adept at doing out of band paper
verification. Secure printing is born out of financial transactions,
everything from cheques to cash to PIN notification.

I think it was Phillip who said that other trust models need to be
developed. I'm not as down on the Web of trust as others are but I strongly
believe that there has to be an ordered set of priorities. Usability has to
be right up there as a near-peer with overall system security. Otherwise as
we've seen a real attack in this context is simply to dissuade people to
use it and developers, especially of security oriented systems can do that
of their own accord.

If you want to get your systems users to help with out of band verification
get them 'talking' to each other. Perry said that our social networks are
great for keeping spam out of our mailboxes yet were busy trying to cut out
the technology that's driven all of this.

Out of band for your banking might mean security printing techniques and
securing your email, phoning your friends.


 Cheers - Bill

 ---
 Bill Frantz| If the site is supported by  | Periwinkle
 (408)356-8506  | ads, you are the product.| 16345 Englewood Ave
 www.pwpconsult.com |  | Los Gatos, CA 95032


 ___
 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] Johns Hopkins round table on NSA and Crypto

2013-09-19 Thread Jens Kubieziel
* Perry E. Metzger schrieb am 2013-09-17 um 23:26 Uhr:
 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/ 

Is there somewhere a recording of this session?

-- 
Jens Kubieziel   http://www.kubieziel.de
Ich bin nicht auf die Welt gekommen, um das Leben zu genießen, sondern
um anderen Menschen Freude zu bereiten. Franz Lehár


signature.asc
Description: Digital signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography