[Cryptography] From Nicaragua to Snowden - why no national standards should be considered in cryptosec

[ianG]

On 27/02/2016 17:04 pm, Stephen Farrell wrote:

>> For example, in Russia
>> we have 4 algorithms of a digital signature, 2 of them are definitely
>> deprecated
>> but 2 others are required to be implemented. So smth like "National" (may
>> be with
>> mentioning the countries) will be ok and non-pejorative.
>
> There's that. But "national" is also no good as a label, as
> AES is national and some national algs are less well vetted/known
> than others.


(
    Just as an aside... Belgians designed the algorithm, the code was 
written by a Brazilian, the Java test rig was created by an Australian. 
  The Dutch in Anguilla did something too, can't quite recall what tho. 
  The other 4 contenders (or 29) were from many countries and spent a 
lot of time analysing the 5 leaders.  All 5 leaders were thought to be 
state of the art of the time.

    Seems non-national to me :)

    The Americans ran the comp and chose the winner.  The algorithm 
however is only mandated for US Government agencies, not for anyone 
else.  Unlike many other standards bodies that also mandate against 
industry.

Sure we know there are always going to be conspiracy theories, but 
frankly, the full NIST comp is as open as any other process we can 
invent.  Again, in SHA3.
)




But that's not an interesting point.  An interesting point is that 
labelling a bad process won't save it.


> And there's also the set of algs that we think are ok, but are
> not yet needed, e.g. codepoints associated with Curve448 might
> not be needed right now, but might move to "good" status later.
>
> Deprecated also doesn't quite seem right for e.g. integer DH
> where we might want to prefer ECDH even though integer DH is
> still fine with sufficient length primes.


Ya.  So the overall problem with consensus seeking is that everything 
must be considered, everyone must have a say.  As we can see on this 
thread and in every other bikeshed, the result is a grand unified theory 
of cryptopolitics, rather than ... a ciphersuite, which is what users need.

Anyone can bring a pander-request to the table, and lobby for it.  Crap 
or not.  Anyone can bring a small RFC for no clear purpose, or a RNG 
that is pre-broken, or argue that an opponent isn't following the latest 
academic attack that is still warm from printing, or or or...

Ontologising the inputs or outputs isn't going to help.

There's no way around this.  If you're going to allow *everyone* a 
voice, then you'll end up with the pander-list.  Which is fine in 
ordinary commercial protocols like HTTP but not good in security 
protocols where we have known, aggressive, enemies that don't follow the 
laws of their land nor the laws of polite IETF society.  AKA the spooks. 
  Add countries to that.

The only alternatives I can think of are diktat of some form.  Of those, 
I prefer the following diktat:

One person of known history and pedigree is chosen to design the crypto 
suite.  That person does it.  That suite lasts for 7 years.  If it goes 
down in flames, so does that person's rep.  Sucks, but the incentive to 
take care is clear.


> And then (for TLS) there's stuff like SRP where almost nobody
> cares and we might not want that code in general libraries so
> maybe that's also better not in the "good" category too.


If nobody cares, then do an experiment?  This is why I consistently 
argued in TCPINC that David Mazieres' group should do it. The whole lot. 
  The notion of starting a competition between 2 opposing designs has 
the unfortunate consequence of handing the NSA another 2-4 years grace 
in mass surveillance.

Nobody should care what the suite is in TCPINC because the stuff can be 
MITM'd by definition.  I know that doesn't stop people reaching for the 
paintbrush, but we should hold the line on general security:  choosing 
any suite is good for TCPINC, choosing two suites is to misunderstand 
everything about the general nature of MITM, threat modelling, security.

( for others:  TCPINC is the generic name for bootstrapping a 
lightweight opportunistic encryption protocol within TCP so the masses 
can get out from the yolk of permanent global mass surveillance. )


...
> Anyway, in the IETF the TLS WG have agreed to try to figure this
> out for TLS ciphersuites. They've not started that work yet, as
> they're busy with TLS1.3 but the bikeshedding will happen there
> in the not too distant future.


TLS is a challenge which cannot be surmounted because the process is 
already too entrenched.  Granted.  No point in arguing about that.



iang