While I agree in principle, as of now the latest commit to the pyaes repo and its latest release to pypi are from 2017...
If 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.
You 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.
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.
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...
While I agree in principle, as of now the latest commit to the pyaes repo and its latest release to pypi are from 2017...
If 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.
You 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.
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.
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...