Carelessness versus craftsmanship in cryptography
blog.trailofbits.com
Carelessness versus craftsmanship in cryptography
1–10 of 20 posts
Re: Carelessness versus craftsmanship in cryptography
#2If AES just specified that you pick a random IV and prepend it to the cipher text, then users of crypto libraries wouldn't need to know what an IV is. Right?
Re: Carelessness versus craftsmanship in cryptography
#3You get what you paid for. Please don't blame, bully or in any way personally attack the authors - they are not obliged to make changes to their (insecure) code that has been provided as-is.
Re: Carelessness versus craftsmanship in cryptography
#4You get what you paid for. Please don't blame, bully or in any way personally attack the authors - they are not obliged to make changes to their (insecure) code that has been provided as-is .
Trail of Bits is charging hefty sums for audits. I suppose they could provide some patches.
Re: Carelessness versus craftsmanship in cryptography
#5If AES just specified that you pick a random IV and prepend it to the cipher text, then users of crypto libraries wouldn't need to know what an IV is. Right?
Right, but AES is a primitive used in a lot of protocols, and they might need to do something different with the IV. The source of randomness is also traditionally something that people want control over, because some platforms can have terrible randomness.
Even high-level libraries like crypto_secretbox still take the nonce separately. They do have a combined mode that prepends the authentication code to the cipher text, and most people who just want to encrypt something should probably look at a higher-level interface like this one instead of directly using raw AES libraries.
That being said, providing an interface where the IV is optional and the default value is a constant instead of random is still insane. That wouldn't be out of place in some Underhanded Crypto Contest where the goal is to create subtle bugs.
Re: Carelessness versus craftsmanship in cryptography
#6You get what you paid for. Please don't blame, bully or in any way personally attack the authors - they are not obliged to make changes to their (insecure) code that has been provided as-is .
Trail of Bits is charging hefty sums for audits. I suppose they could provide some patches.
Patches are a good starting point, and Trail of Bits may have provided them, however they would still need dev time to review, approve, and roll-out...
Re: Carelessness versus craftsmanship in cryptography
#7You get what you paid for. Please don't blame, bully or in any way personally attack the authors - they are not obliged to make changes to their (insecure) code that has been provided as-is .
This argument doesn't hold because paid cryptography libraries aren't any better and equally provide their code as-is.
Re: Carelessness versus craftsmanship in cryptography
#8While I agree in principle, as of now the latest commit to the pyaes repo and its latest release to pypi are from 2017...
Re: Carelessness versus craftsmanship in cryptography
#9You get what you paid for. Please don't blame, bully or in any way personally attack the authors - they are not obliged to make changes to their (insecure) code that has been provided as-is .
Trail of Bits is charging hefty sums for audits. I suppose they could provide some patches.
> He immediately created a security-fix branch and collaborated with Trail of Bits to develop stronger protection for his users.
They are willing to collaborate on fixes.
Re: Carelessness versus craftsmanship in cryptography
#10While I agree in principle, as of now the latest commit to the pyaes repo and its latest release to pypi are from 2017...
So the next and final commit should be a message at the top of the README saying the library is unmaintained and contains serious vulnerabilities and users are advised to move to alternative XYZ.