On Feb 26, 2017, at 2:04 PM, Ron W <[email protected]> wrote: > > From: Warren Young <[email protected]> > > > The PHC scheme would allow Fossil to migrate to something stronger in a > > backwards-compatible fashion: > > The PHC scheme is conceptually good, but is not friendly for use by command > line tools
I wasn’t suggesting that the end user of Fossil type PHC-formatted hashes. That is an implementation detail which would allow Fossil to migrate to something better than SHA1 today, and then to something better than that tomorrow, all in a forwards-compatible way. If I say “fossil up 123abc” in this new world, that should match *any* hash whose first 6 digits in hex form are “123abc”, no matter the hash algorithm. If it matches one artifact hashed with SHA1 and another hashed with SHA2-256, it’s still a “collision” in the Fossil sense, and Fossil will still demand more digits to disambiguate it, just as it does today. If that means we have to modify PHC to encode in hex, that’s fine, because Base64 is not the most interesting part of PHC. The most interesting parts are how it encodes the algorithm used, so that the hash is self-documenting. It means you don’t have to memorize (or encode!) imperfect heuristics like “40 hex digits == SHA1” because 40 hex digits can also be RIPEMD-160 or SHA3-160. (The latter is nonstandard, but it’s possible to configure SHA3 to produce it. I assume there are those who have done this on purpose in software where the developers want to use a stronger algorithm but can’t resize some fixed-width hash field.) _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
