Re: [openpgp] New encryption formats for messaging

[Christoph Anton Mitterer <[e-mail]>]

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?


> 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


> 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.
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.
Nowadays people think that TOFU would provide high security and that NSA
and friends would never dare to abuse that...


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


> 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


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



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

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


> 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? I.e. we could
still use MD5 since problems in it aren't solved by e.g. SHA2?
Or we should still use DES, since an algorithm switch couldn't solve
it's problems?



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

*If* someone does crypto, than probably because he wants to be secure.
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).


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


Cheers,
Chris.