[HTTPS-Everywhere] Draft specification for file used to check for ruleset updates

Maxim Nazarenko nz.phone at mail.ru
Sat Jun 28 09:03:46 PDT 2014

On 20 June 2014 01:19, Red <redwire at riseup.net> wrote:
> On 2014-06-19, 2:07 PM, Yan Zhu wrote:
> > Red:
> >>> Also, it's better to specify SHA1 somewhere in the update.json file in
> >>> case anyone is reading it independently. This could either be an
> >>> additional field, or we could use the format
> >>> "sha1/5R0zeLx7EWRxqw6HRlgCRxNLHDo=" (<name of hash function>/<base
> >>> 64-encoded string).
> >> The fact that SHA1 is used is specified in the first paragraph of
> >> "Verification and Version Checking".
> >> Specifically: "SHA1 is currently being used as the hashing algorithm."
> > Right, SHA1 is in the spec, but it would be better to also include it in
> > update.json itself. That way, if/when we switch to another hash
> > function, someone who is reading update.json or using it to manually
> > verify a ruleset file doesn't need to find the version of the
> > specification that was current at the time of posting or look in the
> > corresponding checkout of the extension code, etc.
> Oh, I see.  Then we can have the extension use whichever hash algorithm
> is specified in update.json.
 Just be careful not to introduce the hash downgrade attack, i.e. only a
few (supposedly secure) hash functions should be allowed.

Best regards,
Maxim Nazarenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140628/ddfd8951/attachment.html>

More information about the HTTPS-Everywhere mailing list