Phasing Out SHA-1 on the Public Web | Hacker News Reader

Phasing Out SHA-1 on the Public Web

blog.mozilla.org

197 pointskungfudoi101 comments

Chrome [1], Edge, and IE [2] are also in various stages along between the continuum of not marking SHA-1 secure, warning about SHA-1, or blocking it altogether.

[1] https://security.googleblog.com/2015/12/an-update-on-sha-1-c...

[2] https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecat...

EDIT: My frustration is that it's a bit difficult to grok who's warning against what when, and who's blocking what when, and who's giving unskippable errors to what when but I'll try to collect and distill this down because right now I have to look it up every time on blog posts that haven't been updated in years (-cough- Google)

My progress on summarizing this can be found at

https://gist.github.com/anonymous/63e5ecb1de2511985255a98bce...

The short version is, if you care about modern browsers, you should be using SHA-256 already. If you care about ancient clients, you should be using SHA-1 still. If you care about both, you need to serve both[1], but your SHA-1 cert most likely expires at the end of this year anyway, unless you've gone through the effort for extraordinary issuance.

[1] you'll most likely need to write code for this, I don't think it's widely supported. If you send SHA-1 to TLS1.0 and SSLv3, that's probably easier than triggering off the signature algorithms extension.

> If you care about ancient clients, you should be using SHA-1 still

I want to point out here that the oldest OS the newest Firefox supports is Windows XP SP2 [0], released 8 years ago, and a free upgrade from the original XP release 14 years ago. Unless you need support for last millennium's hardware you have no excuse for not supporting SHA-256.

[0] https://en.wikipedia.org/wiki/Firefox#System_requirements

Note that I contrasted modern browsers and ancient clients. Client libraries in shipped devices tend to be several years behind state of the art when they were shipped, and live in the field without updates. As an example Symbian didn't ship SHA-256 support in their 9.3 release from 2006, but Firefox shipped support in their 1.0 release from 2004.

Whenever TLS 1.0 starts getting pulled from servers, it's going to be similarly painful. Nokia S40/Asha (last device released in 2014), only supports TLS 1.0, even though TLS 1.2 was 6 years old at that point. Nobody meaningfully supports TLS 1.1, but not TLS 1.2, so let's not hold lack of TLS 1.1 support against them.

(Not to pick on Nokia, they just happen to be an easily identifiable client platform that I'm familiar with)

The funny thing is that data deduplication storage systems work on sha-1 hashes to identify identical data blocks (two blocks are considered equal if the hash is equal - most systems don't care to check for collisions); they kept telling that the likelyhood of collisions is so astronomically small [1] ; i wonder if this statement is still considered to be true.

[1] https://pibytes.wordpress.com/2013/02/09/deduplication-inter...

Security systems must retain collision-resistance even in the presence of adversaries. If your design doesn't have adversaries, you can use cheaper, less secure hashes. Nobody would still recommend SHA-1, though.

I think many systems use two hashing methods to verify this claim (e.g. SHA-1 and MD5.) Are there any known collisions that affect both algorithms?

Using two algorithms together is basically just creating a new hash algorithm (with a longer hash), which could also have collisions.

If you know a technique for making SHA-1 collisions and a technique for making MD5 collisions, it's probably possible to combine the techniques and make a collision for SHA-1-MD5.

You are talking about making a combined hash function from MD5 and SHA-1. Keep in mind that it is not trivial. For instance, if you just output both SHA-1 and MD5, you are actually only as strong as the weakest hash function (trivially for preimage, but also true for collisions, see [1]).

If you are interested in hash function combiners, have a look at Robust Multi-Property Combiners for Hash Functions [2], a recent paper on the topic. It aims at getting several properties at the same time (preimage resistance, collision resistance). For simpler schemes with a single property, just explore the bibliography at the end of the paper.

[1] https://cryptopals.com/sets/7/challenges/52

[2] https://eprint.iacr.org/2016/723

What you are saying is completely irrelevant, because we are talking about checksumming data, not hashing passwords.

The risk that two blocks would hash identically by accident is astronomically small, but there is indeed some possibility that a skilled person might construct two blocks that do.

So as long as your data on disk hasn't evolved intelligence and actively tries to create two blocks with the same hash, your storage system is absolutely fine.

Well, and as long as you're not storing data from users and one uploads some data specifically constructed to collide.

That's not always true: Riverbed Whitewater (now Netapp AltaVault) uses sha256.

Source: I wrote that hash-based dedup code

Very interesting.

Can you tell why SHA256 was chosen? Was it because of the larger hash, or was it a requirement to have a cryptographic secure hash?

Do you know how the hash is used in the Netapp in regard to the remark MichaelMoser123 made: "(two blocks are considered equal if the hash is equal - most systems don't care to check for collisions" [...]

Is it (overoversimplifed ;):

  if sha256(a) == sha256(b)  {
    performDedup()
  [...]

Or is a compare added if the hashes found to be identical:

  if ( sha256(a) == sha256(b) and 
       byteCompare(a) == byteCompare(b) 
     ) {
    performDedup()
  [...]

sha256 was chosen over sha1 because of the larger hash space making collision much less likely. These systems can store 100s of TBs to PBs and at that number of hash blocks you have to start worrying about the birthday paradox.

AFAIK, no sha1 collissions have ever been observed.

That probably won't be true in a year, though. That's why SHA1 deprecation is in full force.

Disabling SHA1 for only a subset of Firefox 51 users after release sounds like it'll cause a lot of confusion. "Is my computer hacked?" "It works for me!" etc etc

Another good reason to not do the nonstop upgrades that FF keeps coming up with. I'm hanging in the upper 40's until this shakes out.

I understand SHA1 is an issue, but I'm also confused by some things. Happy to have web pages be encrypted to keep my personal information from being captured. Not really sure why we are encrypting video streams from Youtube. Is a cat video something that we need to make more secure?

And I agree with the comment that the problems are now coming back to the plethora of CA's that have popped up in the last few years.

> Is a cat video something that we need to make more secure?

If the video you're watching is political in nature and you live in under an oppressive regime, absolutely. Youtube's not just cat videos.

YouTube should sort all of its videos into two groups, one group worthy of being secured and one group not. /s

Probably should be on v45 rather than the upper v4*s if you're not doing upgrades, since it's the extended support release and will receive security fixes. Although opting to not take updates because Firefox is taking a harder security stance going forward seems a bit self-destructive...

Video decoder bugs are not unheard of - unless you want to leave open the possibility for someone to inject content of their choosing into code running on your computer, you lock it down.

> Not really sure why we are encrypting video streams from Youtube. Is a cat video something that we need to make more secure?

You think the Internet is still a toy?

You probably want to follow ESR [0] then. A new version is released for every seventh Firefox version, IIRC, and those are supported (i.e. receive security fixes) for a year.

[0]: https://www.mozilla.org/en-US/firefox/organizations/faq/

Good to know, thanks for the link

> Not really sure why we are encrypting video streams from Youtube. Is a cat video something that we need to make more secure?

Yes, for several reasons. Multiple ISPs have purposefully messed with YouTube and other video traffic, and YouTube reported that after they switched to HTTPS, many of their video reliability issues simply went away.

Also see https://en.wikipedia.org/wiki/Great_Cannon ; it's not safe to load any content over insecure HTTP.

> Is a cat video something that we need to make more secure?

This is about solidarity by increasing the background noise. If only those people who really need it would use encrytion, they were easy to detect and to suppress.

So, please show solidarity with the weak people in our and other societies by encrypting as much non-sensitive stuff as possible.

Thanks for the thought out reply, that makes the most sense.

> Is a cat video something that we need to make more secure?

If I'm hosting a cat video on my website, I don't want my visitors' slimy ISPs adding Javascript-injected ads to my page and my visitors thinking it was me.

But more importantly: There's something very wrong with declaring that certain kinds of content should be relegated to a second-tier, less-secure technical stack based on a judgment that their content doesn't deserve security.

People have answered already but I want to summarize two key facts:

- Browsers are huge attack targets and if you don't update you will be vulnerable to many more vulnerabilities.

- TLS not only provides confidentiality but also integrity. This prevents others from injecting content into the sites you visit, even if you don't care if they know the content.

Mozilla used to have a page that said something along the lines of "Your version of Firefox is out of date. Please update to stay safe and secure. If you don't want to update we recommend that you use the most recent version of another browser to avoid security issues." I can't find this page anymore, and I might have dreamed it but the message is good either way.

Also if you want Firefox to get off of your lawn and stop changing so often you can try the ESR release which has feature releases far less often while still receiving security fixes.

Almost all changes are effectively "staged" like this whether intentionally or not, because people upgrade at different times, and some fail to get updates completely. Making it easy to figure out depends more on writing clear error messages and documentation than on making everyone's configuration change at the same time.

Summary:

> per recommendations by NIST, issuance of SHA-1 certificates halted for the web last January.

> In early 2017, Firefox will show an overridable “Untrusted Connection” error whenever a SHA-1 certificate is encountered.

> overridable “Untrusted Connection” error

Allowing users to click past security warnings is a really bad idea. How is a user supposed to know the difference between untrusted because of SHA-1 deprecation and untrusted because of a MITM?

As far as I know almost all browser security warnings are overridable. The only one that comes to mind that does not have a click-through option is when a HSTS-enabled site fails a validation check.

This one in particular feels very strange, since there's actually nothing bad actively happening with the connection, it's more of a policy decision.

My understanding is that you can't know that nothing bad is actively happening with the connection since SHA-1 is no longer a strong hash, so it's basically (hand-wave) no different from an HTTP connection.

So why don't they present any warning on HTTP connections?

It's not "basically no different" from an HTTP connection, it's strictly better than an HTTP connection, but not as good as a cert made with a more modern hash. (For that matter the same argument applies to self-signed certificates: you're still keeping a third party from snooping on the phishing attempt the MITM is giving you, which is itself a Good Thing.)

I agree, insecure HTTPS should be treated like HTTP. But this issue has been argued to death, especially over self-signed certs, and our side lost.

All major browsers are moving towards this. Starting with the tiny icons changing colors they are beginning to make HTTP as insecure. Yes, it's very slow but at least they have started moving.

If you have explicitly dis-trusted a certificate you can't click-through either.

I think HPKP might also suffer the same issue.

It depends on who you ask, but I personally don't think hard certificate validation failures are a bad thing.

HKPK has the potential problem that losing / compromising 2 keys leaves your site unavailable until the pin expires.

This is a common theme in this thread but I'll re-state it here:

Web browsers cannot reliably distinguish between a configuration mistake and an attack.

For this reason, I think hard HPKP fails are a good thing. For those who opt-in to HPKP, this is a risk one takes in exchange for greater control over certificate validation.

Quite a few are only overridable in about:config, like: (if I recall correctly)

  * DH short exchange keys
  * NTLM1 passwords

I just went digging through the about:config options and couldn't find a way to force SHA-1 off. Why are they gradually rolling this out to beta users if they've purposely downloaded the Developer Edition?

There's a couple fatal errors, ERR_CERT_CONTAINS_ERRORS, ERR_CERT_REVOKED, ERR_CERT_INVALID, ERR_CERT_NOT_IN_DNS: https://github.com/adobe/chromium/blob/cfe5bf0b51b1f6b9fe239... Not sure which one of these catches HSTS failures.

Not allowing users to visit sites they are directing their computers to visit is a worse idea. The computer's job is to do what I tell it to do, not what Mozilla thinks is best for me.

Forgetting this leads to wonderful issues like the eight year old dupe certificate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=435013

The problem is that when there's an adversary in the picture (when there isn't, you may as well not encrypt at all), your computer isn't doing what you tell it to. TLS doesn't work if you don't enforce authentication.

When people visit TLS URLs, they're asking the browser to establish a TLS connection. When attackers make that impossible, it's the job of the browser to refuse, on the user's behalf, to downgrade to an insecure connection.

Splitting hairs. The user is almost never directly controlling whether the connection is to be secured or not, they're clicking on a link, and even less so nowadays with the existence of things like HSTS.

It should be the browser's job to inform the user if it can't meet Mozilla's definition of security, but if accessing the information is more important at the time, it needs to get out of the way with an override and honor the intention of retrieving the information.

If the net effect of the override is that users routinely click through the warnings, then the security of the whole system depends on how well we can educate random end-users on the TLS security model. That's not going to work.

And your alternative of not allowing the user to access what they have clearly stated the intention to access isn't acceptable either.

I feel like we're talking past each other. I'm pointing out that when a user is under attack, they're not getting what they clearly stated they wanted. The only conundrum here is that the browser can't tell the difference between "under attack" and "misconfigured". If you want to bang on that conundrum, OK. But this business about user intent doesn't make sense to me.

But the the user is more often than not, not under attack. Think back to the last ten or so security warnings you go while browsing the internet.

How many of them were a result of a pretty blatant configuration error? Things like self signed certs on personal/toy sites, T+1d expiration, subdomains using the main domain's cert (or vice versa), bad local clock, things like that that?

How many of them were ambiguous?

How many of them were unmistakably fishy?

If your breakdown is anything like mine, it'll be 9/1/0.

I speak of intent because the original person I replied to suggested that security warnings should not be dismissable. I vehemently disagree, because it is my decision to make whether accessing the information I clicked on is more or less important than the risks for the particular class of cert problem that presented itself.

Hide it behind an about:config variable or explicit cert trusting or something else, I don't care. That is still superior to telling me that I can't access something for my own protection.

I'm more sympathetic to this argument, and hiding it behind an about: variable seems like about the right way to handle it.

In fact: apart from the sheer ugliness and cryptographic ass-backwardness of the protocol itself, this is my biggest problem with DNSSEC: it takes the exact same set of failure modes and migrates them to the DNS, where there is no error recovery possible. When DNSSEC configurations break, sites simply vanish from the Internet.

The problem with giving users an option is they tend to hit "yes". The current mass outbreak of cryptolocker is heavily based on users get that "Word has disabled macros" prompt and then going and hitting "enable".

Chrome's BADIDEA is a good middle ground. Advanced users have a workaround. Average users generally don't.

Why is there a difference? At this point we believe that SHA-1 is vulnerable to MITMs.

There are of course plenty of SHA-1-using sites that aren't being MITMed, but there are also plenty of sites with invalid certificates that aren't being MITMed, either (or sites that are being MITMed in benign ways), and the browser doesn't distinguish between those and real MITMs.

> How is a user supposed to know the difference between untrusted because of SHA-1 deprecation and untrusted because of a MITM?

The whole reason SHA-1 is being deprecated is because it's judged no longer strong enough to protect against MITM.

So I'd say it's intentional and desirable to treat SHA-1 like MITM, rather than to try to get the user to distinguish. User's don't have the capacity to distinguish between, and shoudln't have to, any category of "someone may be viewing and/or altering the content in this connection." They are moving to judging SHA-1 such a category.

Except that SHA-1 is strong enough to protect against MITM and will be for the immediately foreseeable future. Well-financed attackers could probably achieve a collision but that doesn't get you very far these days.

Then you disagree with the browser vendors decision to gradually remove support/warn for SHA-1 entirely? They seem to disagree with you.

SHA1 is perfectly fine.

Warning: The above sentence may not be right in 5-10 years so they are starting to shut it down now.

I personally find the schedule rather aggressive. Stop issuing certs this year, block it next year. What's the average cert lifetime? 1-2-3 years? This is gonna give some warnings.

SHA1 may not be defeated yet, but since it has been found weak, we would be foolish to continue using it. It does us little good to wait until it's actually broken. Especially since we have sha2 as a sufficient replacement.

SHA-1 still isn't practical to exploit right now. Conditioning users to automatically click through SSL warnings, on the other hand, can be trivially exploited.

Should SHA-1 be phased out of git, too? I understand that it's more of an issue for certs, but it's still a bit of an issue for anything that uses SHA-1. I'm just asking, not advocating, because the answer will depend on both benefits and costs, and I don't know enough about either in the case of git.

I don't think git's use was really intended for security. That being said it would be interesting to upgrade it and achieve security.

Regardless of whether or not it was intended for security, it is used for security now, via signed git commits and git tags. Lots of projects rely on them, and there aren't good alternatives yet; using third-party services like GitHub without signed git commits is very foolish.

Fortunately it's only becoming possible for attackers to create pairs of messages that have the same SHA1 hash; an attacker still can't create a collision between a message of their choosing and an arbitrary SHA1 hash, and that type of attack is probably a long way off. But that's not much safety margin!

A scheme to generate (and sign) a SHA512 hash that more directly incorporates the full state of the repo was invented, and is used by some projects incl. nodejs

https://github.com/cgwalters/git-evtag

https://github.com/nodejs/node/issues/7579

I personally think it's overkill

Oh, interesting! I do something not unlike that with my OpenTimestamps git commit signing: https://petertodd.org/2016/opentimestamps-git-integration

I don't describe it in that post unfortunately, as I still consider the git tree "rehashing" support to be alpha-level, but I'll look into git-evtag.

Still, I would hope that this is a planned-for possibility, that git might switch hash functions some day. Though it would create repositories that older versions of git can't use, and I don't know if they ever have made a backwards-compatibility breaking change like that.

In addition to what others said, I'm really skeptical as to whether it is possible at all to upgrade to something else. The hash is the object ID for all objects stored in Git, most prominently for commits which are referenced by their commit ID (i.e., the SHA-1 hash) all over the place, from internal datastructures to Github URLs.

Rewriting to e.g. SHA-3 would therefore break a lot of references all over the place. Some can be rewritten automatically, some can't (e.g. commit IDs manually entered into commit messages).

Red Hat uses SHA1 certificates for their CDN [0] (that provides packages for RHEL7 and, I assume, other products).

It is a "private PKI" but their (current) intermediate and root certificates do not expire for a long, long time. Hopefully they'll move to a SHA256 root in the near future.

[0]: https://cdn.redhat.com/

The hash algorithm of a root certificate does not matter, because you explicitly trust the root certificate, and it is only signed by itself.

Their intermediates and end-entity certificates should be updated, but still, the attacks PKIs are concerned about on SHA1 (a preimage attack) can only happen during issuance.

However, if a second preimage attack on SHA1 were viable, all of the above would be invalid, and SHA1 would be permanently weakened for all digital signature uses.

Honest question: why does a SSL certificate need SHA-2? In other words, where does hashing factor into the asymmetric crypto process? So from my cursory understanding of SSL, it uses RSA to exchange a symmetric key which is then used for the remainder of the session.

I'm interested in crypto systems but still getting my feet wet, so a simplified answer would be really appreciated! Also, pointers to any articles or papers would be great.

I might be wrong, but I'm pretty sure that in practice, whenever someone signs some content, they actually sign a hash instead of the entire content so that the signature is a sane size.

If you can create a hash collision between two pieces of content and then get someone to sign one of the pieces of content, then effectively you've gotten them to sign the other piece of content too without them knowing it. This happened a few years ago when SSL certificates still allowed MD5: http://www.zdnet.com/article/ssl-broken-hackers-create-rogue...

It's the hash of the certificate that is signed by a CA. Create a certificate with the same hash and you can transplant the signature. http://web.archive.org/web/20071226014140/http://www.cits.ru... demonstrates this with the MD5 hashes of two different PDF files, a letter of recommendation and a security clearance.

It's common to sign hashes instead of the data, reasons are explained here: http://crypto.stackexchange.com/questions/12768/why-hash-the...

So basically it's used to verify a MAC?

What I'm imagining: CA takes the hash of the certificate, encrypts that with its private key, and appends it to the cert. Client's browser then takes hash of locally stored certificate, and uses the CA's public key to check that the MAC attached to the incoming cert is valid.

I'm guessing SSL uses RSA-PSS[1] or something similar. Guess I'll have to do some reading when I find the time.

[1]: http://www.onefs.com/emc-plus/rsa-labs/historical/raising-st...

Certificates have a "tbsCertificate" component which holds almost everything (issuer, expiry, distinguished name, etc) except for the signature. The CA takes HashAlgo(tbsCertificate) and signs it with its issuing key.

The relying party can then take HashAlgo(tbsCertificate) and see if the CA signed that value.

Make sure you do not confuse encryption with signing. The hash is not private, so you do not need to hide its contents. I'm not sure if you can call it a MAC, because there is no key involved. It provides integrity guarantees, but the hash itself does not provide any authenticity guarantees; only the signed hash does.

Awesome. Thanks for the clear explanation!

Doesn't matter when you have CAs known to have backdated certificates to avoid the SHA-1 deadline and all they get is a temporary suspension with none of their issued certs being revoked. The weak point of PKI is not the crypto, it's the CAs, of which there are too many and for whom there is little to no accountability.

Revoking certs doesn't ascribe accountability to the CAs, it ascribes accountability to the end users. Which isn't a bad thing, per se - it's just not one we're set up for right now. (If, for instance, the CAs started spreading FUD about each other getting revoked and encouraged users to buy and configure two certs from two different CAs, they'd make more money and we'd be in a better place security-wise.)

Preventing the CA from taking any new business ascribes accountability to the CA.

Hrm, this just made me think. Is it possible to provide two different root chains for a X509 certificate? I'm guessing not, but if so depending on the business it might not be a bad idea (especially with HSTS, pin both intermediate roots so if one is revoked you could rely on trust to your secondary to continue service without hoping users hit your site after you updated your rules but before the root was revoked or distrusted).

You can't do this with a certificate (a certificate is a digital signature, and signing with two different CA keys gives you two different signatures). I suspect it's possible to do this with two different certificates for the same server key, presenting the backup leaf certificate as one of the certificates in the "chain" - SSL clients tend to just take the entire list of certificates and find an order for them, because server operators / implementations don't reliably send them in the right order. I don't know what clients deal with this well.

Usually you'll have enough lead time to configure your servers to send the other certificate, though. All you need to do is buy it in advance and have it ready to deploy.

And yeah, with HSTS you can definitely pin multiple intermediate roots.

I figured as much, my knowledge of X509 certs ends at knowing "generate a CSR, get it signed, install it" and operating a couple Dogtag CA's as part of FreeIPA.

Having a secondary cert ready to be swapped out with an Ansible playbook (or whatever your tooling of choice is) and ensuring both intermediate roots are pinned seems to be the best way to handle this then. Good to know!

The TLS specs don't allow for that, each certificate (after the first) must have signed the previous certificate. Many client libraries are forgiving of chain issues, but not all, so it's going to get really nasty, really fast.

It wasn't just a suspension - they got kicked out and may only reapply after a year. Only if they pass strict scrutiny will they ever be re-admitted.

Not to mention not being able to do business effectively for a year is basically a death sentence.

"We sell certificates, but they won't work in Firefox, and maybe Chrome or IE if Google and Microsoft follow suit". Doesn't exactly sound like a vendor I'd purchase anything from.

Do I understand correctly, when Mozilla says:

In early 2017, Firefox will show an overridable “Untrusted Connection” error whenever a SHA-1 certificate is encountered that chains up to a root certificate included in Mozilla’s CA Certificate Program. SHA-1 certificates that chain up to a manually-imported root certificate, as specified by the user, will continue to be supported by default; this will continue allowing certain enterprise root use cases, though we strongly encourage everyone to migrate away from SHA-1 as quickly as possible.

This means that self-signed certificates, approved as an exception in browser, will continue to work because they are do not chain up to a root certificate included in Mozilla’s CA Certificate Program? I.e. if user has confirmed an exception for self-signed certificate, it is not impacted by this change in Mozilla?

The signature on a self signed certificate doesn't matter as the certificate itself is trusted.

However if you add your own CA then yes, I believe it will continue to work for the near future. (You should be moving away anyways though ;) )

If you want to test out this behavior before it rolls out, you can set security.pki.sha1_enforcement_level (per Gervase Markham).

A value of 1 means "entirely forbidden", a value of 3 means "forbidden for public roots".

I can't speak for the behavior when using any other value.

What about BitTorrent? It also heavily uses SHA1 - basically for everything from computing infohash to data integrity checks.

Well, a nation state attacker might be able to produce a fake block filled with garbage for a file and have your client accept it.

Unless BitTorrent relies on digital signatures somewhere, that's probably the worst of it.

Or worse, use it to infect the victim if it's executable/exploitable.

They say that this won't affect any SHA1 certificates signed by a root that has imported and trusted, but there's a lot of devices that ship with their own self-signed certificates installed. I hope all the vendors have away from SHA1 or there might be a lot of "broken" devices.

Remember that if you are trusting the cert itself this is irrelevant because you aren't verifying the chain (which is the part using the SHA1 hash). I presume this is what most embedded devices do. But yes, if you imported a SHA1 root you should probably consider distrusting it.

what about retiring TLS 1.2 then?

[banking industry gasps]

Did you mean TLS 1.0? Retiring 1.2 seems a bit premature, since 1.3 isn't finalized.

no I was talking TLS 1.2

https://www.ietf.org/mail-archive/web/tls/current/msg21278.h...

What about git? It also heavily uses SHA1

See this sibling thread about the same topic: https://news.ycombinator.com/item?id=12738567

Reply on news.ycombinator.com