[Cryptography] RSA equivalent key length/strength

ianG iang at iang.org
Thu Sep 26 02:52:39 EDT 2013


On 26/09/13 02:24 AM, Peter Fairbrother wrote:
> On 25/09/13 17:17, ianG wrote:
>> On 24/09/13 19:23 PM, Kelly John Rose wrote:
>>
>>> I have always approached that no encryption is better than bad
>>> encryption, otherwise the end user will feel more secure than they
>>> should and is more likely to share information or data they should not
>>> be on that line.
>>
>>
>> The trap of a false sense of security is far outweighed by the benefit
>> of a "good enough" security delivered to more people.
>>
>> We're talking multiple orders of magnitude here.  The math that counts
>> is:
>>
>>     Security = Users * Protection.
>
> No. No. No. Please, no? No. Nonononononono.
>
> It's Summa (over i)  P_i.I_i where P_i is the protection provided to
> information i, and I_i is the importance of keeping information i
> protected.


I'm sorry, I don't deal in omniscience.  Typically we as suppliers of 
some security product have only the faintest idea what our users are up 
to.  (Some consider this a good thing, it's a privacy quirk.)

With that assumption, the various i's you list become some sort of 
average.  This is why the security model that is provided is typically 
one-size-fits-all, and the most successful products are typically the 
ones with zero configuration and the best fit for the widest market.


> Actually it's more complex than that, as the importance isn't a linear
> variable, and information isn't either - but there's a start.
>
> Increasing i by increasing users may have little effect on the overall
> security, if the protecting the information they transmit isn't
> particularly valuable.


Right, and you know that, how?

(how valuable each person's info is, I mean.)


> And saying that something is secure - which is what people who are not
> cryptographers think you are doing when you recommend that something -
> tends to increase I_i, the importance of the information to be protected.


2nd order effects from the claim of security, granted.  Which effects 
they are, is again subject to the law of averages.


> And if the new system isn't secure against expensive attacks, then
> overall security may be lessened by it's introduction. Even if Users are
> increased.


Ah, and therein lies the rub.  Maybe.  This doesn't mean it will.

Typically, the fallacy of false sense of security relies on an extremely 
unusual or difficult attack (aka acceptable risk).  And then ramps up 
that rarity to a bogeyman status.  So that everyone is scared of it. 
And we must, we simply must protect people against it!

Get back to science.  How risky are these things?


> I have about 30 internet passwords, only three of which are in any way
> important to me - those are the banking ones. I use a simple password
> for all the rest, because I don't much care if they are compromised.
>
> But I use the same TLS for all these sites.
>
> Now if that TLS is broken as far as likely attacks against the banks go,
> I care. I don't much care if it's secure against attacks against the
> other sites like my electricity and gas bills.


(You'll see this play out in phishing.  Banks are the number one target 
for attacks on secure browsing.)

> I might use TLS a lot more for non-banking sites, but I don't really
> require it to be secure for those. I do require it to be secure for
> banking.


You are resting on taught wisdom about TLS, which is oriented to a 
different purpose than security.

In practice, a direct attack against TLS is very rare, a direct attack 
against your browser connection to your bank is very rare, and a direct 
attack against your person is also very rare.

This is why for example we walk the streets without body armour, even in 
Nairobi (this week) or the Beltway (11 years ago).  This is why there 
are few if any (open question?) reported breaches of banks due to the 
BEAST and other menagerie attacks against TLS.

We can look at this many ways, but one way is this:  the margin of fat 
in TLS is obscene.  If it were sentient, it would be beyond obese, it 
would be a circus act.  We can do some dieting.


> And I'm sure that some people would like TLS to be secure against the
> NSA for, oh, let's say 10 years. Which 1024-bit DHE will not provide.


Well, right.  So, as TLS is supposed to be primarily (these days) 
focussed on protecting your bank account access, and as its auth model 
fails dismally when it comes to phishing, why do we care about something 
so exotic as the NSA?

Get back to basics.  Let's fix the TLS so it actually does the client - 
webserver auth problem first.

1024 is good enough for that, for now, but in the meantime prepare for 
something longer.  (We now have evidence of some espionage spear 
phishing that bothered to crunch 512.  Oh happy day, some real evidence!)

As for the NSA, actually, 1024 works fine for that too, for now.  As 
long as we move them from easy decryption to actually having to use a 
lot of big fat expensive machines, we win.  They then have to focus, 
rather than harvest.  Presumably they have not forgotten how to do that.


> If you really want to recommend 1024-bit DHE, then call a spade a spade
> - for a start, it's EKS, ephemeral key setup. It doesn't offer much in
> the way of forward secrecy, and it offers nothing at all in the way of
> perfect forward secrecy.
>
> It's a political stunt to perhaps make trawling attacks by NSA more
> expensive (in cases where the website has given NSA the master keys [*])
> - but it may make targeted attacks by NSA cheaper and easier.
>
> And in ten years NSA *will* be able to read all your 1024-bit DHE
> traffic, which it is storing right now against the day.


In ten years, the NISTs, the committees, the vendors, and the CAs will 
still not have addressed the number one threat to users -- that's the 
i's in your equation.  See also Lynn Wheeler's post about the 
persistence of ignoring the customers' risk.

But I'm pretty confident that in ten years, they will have addressed the 
1024 limit that annoys the NSA.  That's the power of the bogeyman.


> [*] does anyone else think it odd that the benefit of introducing
> 1024-bit DHE, as opposed to 2048-bit RSA, is only active when the
> webserver has given or will give NSA the keys? Just why is this being
> considered for recommendation?
>
> Yes, stunt.


I don't disagree.  Hopefully, a few more of these stunts will finally 
convince them that they can't go on like this.  In military thinking, we 
call it preparing for the last war.

In the meantime, if they are going for a stunt, don't we want it to be 
the most convenient, cost-effective stunt?  So they can get back to 
serious business?  1024 sounds fine...



iang



PS: btw, was this whole debate about a BCP?  If so, it is a woftam.  Any 
time spent on best practices is lost to society.  You'll never get those 
seconds back, guys.


More information about the cryptography mailing list