Login.gov encryption is badly designed

Scrypt isn&#x27;t badly designd. It&#x27;s also difficult to misuse.<p>This is like saying &quot;bcrypt is badly designed.&quot;<p>Note that you are specifically attacking scrypt with the title -- &quot;login.gov encryption&quot; can be substituted with &quot;scrypt.&quot;<p>If you were to say it&#x27;s illegal for them to be using scrypt since scrypt is not an approved KDF, that would carry more weight.<p><i>Cryptographic flaws<p>1. scrypt is used as password-based KDF, which violates NIST 140-2</i><p>This isn&#x27;t a cryptographic flaw! The phrase &quot;cryptographic flaw&quot; means something.<p><i>5. hash(E) is stored right next to the ciphertext from (4). Who thought that storing a hash of the encryption key right next to PII ciphertext encrypted with that key was a good idea?</i><p>Storing the hash of an encryption key is fine, as long as the hash function is strong.<p>It&#x27;s frustrating that a government website is making solid cryptographic choices and then being lampooned like this. It would be far more productive to make scrypt an approved NIST KDF.

This is mostly complaining about a lack of FIPS 140 compliance. While that might be a regulatory issue for a .gov site, technically-speaking FIPS compliance is a hinderance to building a sound system, not an aid.<p>Putting that aside, there might be some valid points in here: using Hash(IKM + nonce) to generate a key is probably not ideal, depending on what Hash is. That&#x27;s generally a job for HKDF. The post also mentions a &quot;non-approved KDF&quot; elsewhere, but doesn&#x27;t say what it is.<p>On the other hand, storing Hash(key) isn&#x27;t immediately an issue unless something else in the scheme depends on Hash(key) being secret, but the post implies without justification that it&#x27;s some sort of obvious error.<p>So there might well be some issues here, but this post doesn&#x27;t provide sufficient detail to condemn login.gov out of hand.

This is a rather sensational title for an article that amounts to &quot;Login.gov does not use FIPS 140-2-compliant cryptography&quot;. Its main argument (aside from point 5) appears to be that scrypt is used in multiple locations, without passing judgement on scrypt itself.<p>Given that this is a US government-run system, this is still a compliance problem, but that&#x27;s a different issue.

I opened an issue on their bug tracker a couple days ago because I had more fundamental questions about how their algorithm was designed.<p>HN comment: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15204989" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15204989</a><p>Github Issue: <a href="https:&#x2F;&#x2F;github.com&#x2F;18F&#x2F;identity-idp&#x2F;issues&#x2F;1665" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;18F&#x2F;identity-idp&#x2F;issues&#x2F;1665</a><p>Now I may be misunderstanding their implementation, but it seems to me actually worse than &quot;this isn&#x27;t FIPS 140&quot;. I take no issue with their use of scrypt at all. The complaints in this Gist actually seem to miss the mark to me.<p>The problem isn&#x27;t scrypt, or storing a hash. The real problem is storing <i>d</i> which, seems to me, defeats the purpose of using an HSM in the first place!<p>Again, with the disclaimer that I&#x27;m not 100% certain that&#x27;s what they&#x27;re doing, it&#x27;s just what the documentation says, and what it seems like is happening from reading the Ruby code. I don&#x27;t develop in Ruby, but while the language is fairly easy to read, with all their variables named &#x27;encryption_code&#x27;, &#x27;encryption_key&#x27;, &#x27;encrypted_key&#x27;, &#x27;encrypted_code&#x27;, etc. it&#x27;s easy to get lost.<p>EDIT: Can someone please co-validate my analysis please? Or please tell me what I got wrong! From what I can see, the design is obviously broken. I don&#x27;t consider myself qualified to find flaws in other people&#x27;s crypto so, when I find obvious flaws in what should be well designed crypto I get a little freaked out.

I don&#x27;t think &quot;NIST&quot; approved is that compelling of an argument.<p>If the author wishes to identify known vulnerabilities, that would be interesting.<p>FIPS has some various issues that actually increase vulnerability and not decrease it. Eg, FIPS approved OpenSSL was always an anchor that caused more problems than it solved.

While there is some weird design in Login.gov, this particular report is mostly generating giggles among crypto engineers I know.

What an immature analysis with click-bait title, I was expecting something big to read and it turns out he was just not happy about the site doesn&#x27;t comply to NIST, and using scrypt is a <i>flaw</i>? Seriously?

Also note: scrypt ends with a PBKDF2 round, so if PBKDF2 is acceptable then scrypt may not actually be a problem. Legally speaking you might be able to ignore the use of the SMIX (including Salsa20) and the HMAC entirely as long as the final PBKDF2 uses a FIPS 140-2 acceptable hash function.

Can anyone explain why scrypt would be inadequate or flawed?

Hey, at least their transport security gets an A+ from SSL Labs. Honestly, I still find a lot of government sites, particularly state governments that get F&#x27;s because they are still using SSL and 56 bit ciphers.<p><a href="https:&#x2F;&#x2F;www.ssllabs.com&#x2F;ssltest&#x2F;analyze.html?d=login.gov&amp;latest" rel="nofollow">https:&#x2F;&#x2F;www.ssllabs.com&#x2F;ssltest&#x2F;analyze.html?d=login.gov&amp;lat...</a>

The construction seems bad, but FIPS isn&#x27;t anywhere close to being as good as NACL, and scrypt isn&#x27;t the enemy. Bad constructions, lack of nuance and faith in certifications are the enemies.

Am I the only person who suspects this is a work of performance art?

Ouch

Is anyone really surprised?