On Thu, Feb 23, 2017 at 7:02 PM, <[email protected]> wrote: > > Date: Thu, 23 Feb 2017 17:01:56 -0700 > From: Warren Young <[email protected]> > Subject: Re: [fossil-users] Google Security Blog: Announcing the first > SHA1 collision > > The PHC scheme would allow Fossil to migrate to something stronger in a > backwards-compatible fashion: > > https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md > > That is, if the hash argument in the F, P, and Q cards is not 40 > characters and it has a suitable prefix, it’s a new-style hash, else it’s a > legacy SHA-1 hash. >
The PHC scheme is conceptually good, but is not friendly for use by command line tools like Fossil or git. This is mostly because it uses $ as its field introducer, so will quoting. Also, the Base64 encoding relies on both upper and lowercase letters, so is more prone to typographical errors. I suggest a simpler scheme that provides the benefits of PHC in a more command line friendly way. Use ^ as the prefix and data introducers. The prefix would have a 1 character field for the artifact type, followed by the nonce. Then a second ^ separates the prefix from the data, which will be the hash. Base64 encoding would make the hash string use fewer characters while continuing to use the hexadecimal encoding would be less prone to typographical errors. Example: ^m1234567890^ab4c90e2..... m is the artifact type. Suggest m for manifest, c for control, etc.
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
