Re: [openpgp] SHA3 algorithm ids.

[ianG <[e-mail]>]

On 11/08/2015 11:10 am, Werner Koch wrote:
...
> We have a lot of experience in how to deploy new algorithms and we are
> very conservative here.  My request for adding SHA3 algo ids does not
> mean in any way that I endorse its use or would even suggest that
> 4880bis should contain a SHOULD or MAY for implementing such an
> algorithm.  When we come to the point on deciding on algorithms I would
> suggest something like this:
>
>   - Implementations MUST implement SHA-1.  Implementations MAY implement
>   - other algorithms.  MD5 is deprecated.
>   + Implementations MUST implement SHA-1 and SHA2-FIXME.  Implementations
>   + MUST NOT implement MD5.  Implementations SHOULD NOT implement
>   + SHA3-xxxx.  Implementations MAY implement other algorithms.
>
> The algo ids are a different case and I would be fine with the RFC-7120
> method.  Iff the unexpected case happens that a severe weakness in SHA2
> is found, the pre-allocated SHA3 ids will allow us to quickly switch to
> SHA3.  Isn't that the whole point of SHA3 being plugin-in replacements
> for SHA2?
>
> I suggest to use a different thread for discussing algorithm selection
> because that is a different topic than assigning algorithm ids.



Hmmm... I understand that.  What I'm not convinced of is that at the 
current time we can sensibly allocate the numbers.

As far as I can see, to sensibly allocate the numbers, we'd want:

   * to choose which SHA3 we're going for.  This not only means 
addressing the additionals (like the 4 lengths) but also resolving the 
uncertainty (perhaps in my mind only) about SHAKES.

   * to build a more comprehensive alg-failure recovery strategy.  By 
this I mean, more than handwaving at SHA3 as a potential drop in; 
making it the actual drop in with a process by which we trigger that 
move and a series of events listed that we anticipate happening;  text 
in the draft that lays that out;  etc.

Otherwise, we're fortune gazing.

(It may sound like I'm engaging in waffly rhetoric again - but there is 
a known discipline for this.  It's called *disaster recovery* and it's a 
required component of many compliance programmes, taught and certified 
in various places.  There are many people who know how to do this stuff, 
it's just that it is a relatively new and/or infrequent delivery in the 
open source crypto world.)



iang