On 3/11/2015 06:54 am, Nils Durner wrote:
Hi Ian,
I agree with all the rest, but can we also deprecate some old stuff as
well?
Can we construct a plan e.g., that no existing S2K be used with new
keys and the new form not be used with old keys?
I have made salt-based methods mandatory in my patch:
+Implementations MUST generate S2K specifiers that include salts
+(either type 2, 3 or 4), as simple S2K specifiers are more vulnerable to
(type 2 should actually be "type 1")
+dictionary attacks. Use of Argon2i is RECOMMENDED as it offers
+protection against massive-parallel and side-channel attacks. When
+reading S2K specifiers that do not include salts, implementations SHOULD
+issue a warning about potentially insecure methods being used. When
+reading S2K specifiers other than Argon2i, implementations SHOULD issue
+a warning about outdated methods being used.
We can of course raise the bar by excluding types 1 & 3 entirely.
That's what I would do. Mode 4 is the only produced option in the new
format.
+ Implementations MUST write in Argon2i and SHOULD read old formats.
Implementations will of course offer options to add back in 0,1,3,
especially where the reading code is stuck on old format, and the
writing code is new format.
But they won't be compliant. And we can ostracise them accordingly,
tell them they're using worse than MD5 and they're to blame for global
warming and bad coffee.
iang
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp