Re: [openpgp] New encryption formats for messaging

[ianG <[e-mail]>]

On 23/03/2015 19:59 pm, Christoph Anton Mitterer wrote:
> On Mon, 2015-03-23 at 18:12 +0000, ianG wrote:
>> On 18/03/2015 23:38 pm, Christoph Anton Mitterer wrote:
>>> Looking at the context you come from (Yahoo) I must note, that the big
>>> players seem to have discovered security recently ... o.O
>> Hmmm... so our technique is to punish people for wanting to improve.
>> Grand...
> Where did I "punish" someone and/or where is my observation wrong?


Yahoo and google are at the forefront of secure email delivery.  They 
are trying something nobody else has got anywhere near - so I don't see 
how they can be called laggards.

(Assuming that is we debunk the joke of security known as S/MIME... 
which was deployed but was crippled by committee-design.)


>> New to some, but it has a long history:  Kerckhoffs' 6th principle:
>>
>> "6. Finally, it is necessary, given the circumstances that command its
>> application, that the system be easy to use, requiring neither mental
>> strain nor the knowledge of a long series of rules to observe."
>>
>> Writing about cryptography communications systems in 1883.
>>
>> http://www.financialcryptography.com/mt/archives/000195.html
>
>
>> I think this is simply wrong.  This is no principle.  TOFU has proved
>> itself.
> Then we can probably abolish fingerprints verification in the next
> versions of OpenPGP implementations altogether,... if TOFU works, why
> should anyone bother to check their keys o.O


The essence of TOFU is that it works in default mode, and gives you 
tools to do better if you so desire.  Now, of course, the concept works 
so well that one never bothers to check for the most part, so 
fingerprint verification could be dropped and would still provide more 
security than not using it.  Which is the goal.  So what you suggest is 
not incompatible with the goal.

But the PGP community came from a different age, so they do often check. 
  Add, they have turned it into a ceremony, one that binds the community 
at least for the time of the 'party'.  So I doubt we'll get rid of it 
just because it's only adding one more 9 to the 99.909% good enough.


>> If you don't want to use it, that's fine, but the notion that
>> it's "not secure" is simply rubbish because security is a relative risks
>> thing, not an absolute thing, and it is extremely unlikely
> I kinda amused every time security based on such assumptions.


What other basis is there for security other than risk?

> Some 5 years ago, the masses still thought that they're not victims of
> mass surveillance and that their emails and data would be safe.

Yup, and the vendors figured that the masses aren't important enough to 
provide security.  Go figure.  As you point out, Yahoo is late to the 
game.  But Mozilla and Microsoft have always been emotionally contorted 
over it, and google has only recently started being serious, before 
there mantra was "all your data base belong to us'.  The only player 
that was ever serious about *the user* was Apple.

And they *all* promote the security-barrier called PKI/x.509, which 
delivers to compliance customers, and distracts from overall security by 
selling a tired old cold war military model as something to protect 
banks from phishing.  Go figure.

> Nowadays people think that TOFU would provide high security and that NSA
> and friends would never dare to abuse that...


Bring it on.  The point of improving security is to get from here to 
there, and actually improve the result.  Those who push the old 'perfect 
security models' mantra typically end up with an extremely narrow set of 
compliance customers, or nothing.  E.g., SSL.

Here in the PGP community we are *not interested in compliance* so much 
as actual ordinary users.

(Which isn't to say we don't come into connection with the compliance 
world;  we do because business models force us there from time to time. 
  But hearts and minds here are about real security delivered, not paper 
calculations.)


>> Empirically, I just today got my first 419 hit on Skype, which was set
>> up to let others see my name - their mistake on default install.  After
>> about a decade of usage?
> Well, NSA and friends probably don't bother to attack systems like Skype
> on the crypto level, one can be quite sure that they have other means
> for these =)


Well, we know they now have direct access.  No need to speculate.

But the fact remains:  Skype has other than yesterday never directly 
harmed me.  Can't say the same for email, browsing, ...

>> Even including the notion that Microsoft now copies it all to the NSA,
>> that's still only 4 parties with capability to connect to me:  Me, my
>> friends, Microsoft and NSA.
> uhm... great? o.O


So, what's my risk?  Microsoft (yawn).  NSA could get narked at my 
repeated jabs at their Stasi behaviour, and stop me at the border.  Grab 
my skype records and accuse me of naughty behaviour.  OK, I'll take that 
risk.

Meanwhile:  I've actually lost non-trivial fortunes because my 
counterparties turned around and attacked me.  I'm bombarded every day 
with spam.  I have to train my family in phishing because the browser 
vendors don't react or when they react, they PKI-me-harder rather than 
looking at the information being rendered to my mother.

Granted, if I worked at a Belgian ISP or SWIFT or my payments biz took 
off in a bad-ass way, I'd be terrified of NSA.


>>> To be honest, Yahoo, doesn't have the best security record, and in
>>> general I wouldn't trust any web-based crypto app regardless of who it
>>> wrote.
>>>
>>> That being said, I agree that it shouldn't be easy to make a well
>>> designed crypto system insecure by settings - but not if this means that
>>> one takes away valid functionality from the more experienced users.
>>
>> Why do you prioritise "experienced users" above the lesser experienced?
>>    Do they pay more money?  Is this the Church Of BOFHs?  Do they pay
>> their dues by helping others?  From your writings it seems unlikely...
> Actually I don't. I just don't prioritise lesser experienced users over
> experienced ones.
> What I prioritise is the intention of crypto, which is security.


Security is only measured by delivered results.  Let's say you improve 
the lot of the experts by offering them cipher suites to choose from. 
Hypothetically that improves the 0.1%, those that actually know what 
those words mean.  OK, 1 billion browser users, that would say about 1 
million know what a cipher suite is.  Exaggerated, but let's see where 
this goes.

Let's say we double their utility.

But, putting in vanity ciphers as we used to call them causes 
complexity.  A lot of problems in SSL would sweep away if we cut that 
crap out.  E.g., Heartbleed and somewhere it was claimed $500m costs... 
  So, let's say this all costs 1% for the masses.

Result:

Security = 1,000,000 * 2 + 1,000,000,000 * 0.99

Guess what?  Only the security delivered to the masses matters.

Which is why Skype worked and everything else fell in a hole.  Simple maths.


>>> b) Why should there be only one?
>>> I think its a wrong assumption that code will become more secure by
>>> supporting less algos/systems.
>>> If a project cannot develop/maintain more of them securely it's rather a
>>> sign for lack of funding/manpower.
>> Ah.  So you see that handling more algorithms is a cost for big
>> companies to meet and therefore a barrier to entry which makes for less
>> choice and eventual balkanisation.  What about opportunity cost - time
>> spent managing and debugging algorithms that are rarely if ever used -
>> could be better spent on getting more usability?
> The biggest "usability" problem we likely have nowadays in crypto is
> that people would need to understand what they do and mutually
> authenticate each other.


Well, right.  Systems that try and "authenticate" each other are 
typically usability nightmares.  Change the paradigm.

> Apart from that we have quite nice UIs at all levels, don't we?
> gnupg is actually quite nice for people who want to use command line, we
> have fine tools like enigmail.


Not for the masses, sorry, not of any interest.


> I somehow have the feeling, that for many people "usability" means not
> noticing crypto at all, but I guess that just won't work.


Skype.

(Sad to say, it got rolled before it was sold to Microsoft, and the NSA 
got their dream entre.  Oh well -- like we say, there's no such thing as 
a complete security model ... there's always a way around.)

But in an elegant way, that provded the K6 hypothesis.  Skype was so 
darn successful that the NSA had to 'buy' its way in, breach the company.

GSM - killed the serious risk dead, which was the paparazzi listening in 
to the famous doing sex talk.  And nobody noticed!


>> That argument didn't work.  Basically when ever a problem was found, it
>> couldn't be solved by an algorithm switch, 9 times out of 10.  The one
>> time that a problem was found, it was solved by ... a switch *backwards*
>> to RC4.  Not exactly a happy result.
> So problems in the alogs themselves don't count for you?


Of course they count.  But, they are pretty much down the bottom of the 
list.  Check it out, do some historical research.  If you're worried 
about a crypt algo breaking, you ain't in the security game, you're in 
the cryptography game.

> I.e. we could
> still use MD5 since problems in it aren't solved by e.g. SHA2?


MD5 was deprecated in 1995 by SHA0.  Then 3 months later SHA0 was 
deprecated by SHA1.  I know, coz we cursed and changed.

SHA1 was deprecated in favour of SHA2 sometime early 2000s.

If anyone is using MD5 they're negligent.  If they're using SHA1, then 
they'd better be sure it ain't a collision risk (I do and it isn't) and 
if goes full belly up they still won't be in trouble.


> Or we should still use DES, since an algorithm switch couldn't solve
> it's problems?


to channel Santayana, those who don't study their deprecation history 
are doomed to have their systems deprecated?


>>>> A3. Do not specify things which are infeasible to thoroughly test.
>>>> This implies avoiding combinatorial complexity, which the OpenPGPv4
>>>> spec doesn't.
>>> As above, I doubt you can really check every combination, and I wouldn't
>>> want to sacrifice too much, just for being able to do so - especially
>>> not diversity of algorithms.
>> When has diversity of algorithms ever bought user advantage?
> Nothing in that his screen becomes more colourful or that his
> "experience" would be more like 4K than just HD.


So, marketing.  Getting an upgrade to earn the fee.  OK.

> *If* someone does crypto, than probably because he wants to be secure.


Not really.  Vendors choose crypto because of their mastery of the 
security model (I'm being sarcastic here, anyone who uses SSL has no 
clue as to the security model) and that fits into the holistic business 
approach.

Very few users - the masses - rush out and say "I wanna six-pack o' 
crypto and 3 jars of authentication with some random side orders..."

It is *myth* perpetuated by the x.509/PKI tribe that "choosing crypto" 
means "wanting security".  This is part of the careful marketing edifice 
that was used to sell certs to an blase public.  Because they didn't 
want it, some elements were forced into being embarrassed to use it, and 
the rest is compliance history.  Also, it's part of the marketing 
against self-signed certificates;  if users "choose" certificates it is 
because they "want" security which is not allowed to include MITM 
possibilities so we have to deny self-signed certs.  Or some such sophistry.

Sorry 'bout dat!


> So if diversity enhances security or at least allows one to switch more
> easily in case it gets necessary (which of course you disputed above),
> then it benefits the user by helping with his original goal (being
> secure).


Yeah, sure.  Just doesn't work in practice, and doesn't work in theory, 
if we actually think about how it is supposed to work.


>> I can think of (been told) one case:  the "Russians GOST" requirements.
>>    Frankly, I'm not that keen to let them do that.  If *every* government
>> did it, then we'd be in a pickle, and we'd not be talking to any of them
>> at all.  So why do we care about the Russians?
> Agreed. But hopefully the whole crypto standardisation would go anyway
> rather into community hands now.
>
>
>>> Disagreeing with the "We only need two hash functions at most.".
>>>
>>> Diversity is good (of course we should only include secure algos),
>>> especially when one expects that each algo sooner or later sees
>>> weaknesses.
>> Well, sure, on paper.  But if you had a process to switch then you could
>> also ... use that process to switch!  Why not just roll out v+1 ?
> How long does it usually take us to roll out v+1? Take SSL/TLS, how many
> years have SSL still been used while it should have not? The same for
> MD5, the same for RC4, and so on.


I measured a 3.5 years OODA cycle for the first big SSL oops.  I haven't 
been following the others but I have a feeling they've got a lot faster.

Point is however, it's still all ad hoc.  We don't actually know what 
we're going to be switching, and pretty much each time it is a download 
/ reinstall.

So why not have a v+1 waiting in the wings?  Each new generation is 
substantially better and is far more likely to cover anything uncovered.

My point isn't that is what should be done.  But that right now we've go 
no plan.  So *anything* would do better than what we had right now.



iang