Cryptography - encryption vs signatures

[JCapriotti]

What's the issue?
Section 4.9.4 (Testing for Weak Encryption) includes a few notes about digital signatures.

I'm curious if the section is meant to include signature information, since to me (a novice) encryption and signatures are two different but related aspects of cryptography.

How I noticed this is the Basic Security Checklist has a recommendation for "asymmetric encryption" methods and separately (subsequent bullet), a note about using RSA for signatures.

I can't tell if the first bullet is only about encryption, or if would apply to signatures as well.

How do we solve it?
If the section is in fact only talking about encryption and not signatures, would it be wise to add a section about signatures?

Otherwise, if it meant to cover both, maybe some clarity/additions around acceptable signature algorithms would be good.

Would you like to be assigned to this issue?

• Assign me, please!
  With some guidance as to what the intent of that section is, I could do a PR.

[ThunderSon]

I see the point you're trying to raise. Thank you for bringing this forward.
That section definitely has different vibes inside of it, no wonder it would confuse anyone reading it.

@rbsec @kingthorin what do you think about this? That section covers cryptographic implementations, and not only encryption.

[kingthorin]

I think adding some info on signatures would be a good move.

[rbsec]

@JCapriotti for reference, elliptical curve should pretty much always be preferred over RSA, and if you do have to use RSA, your keys should always be at least 2048 bits (regardless of whether you're doing encryption or signatures).

@ThunderSon to be honest, I think the entire guide could probably do with rewriting. Most of the content in it isn't wrong, but it's essentially a list of bullet points on good (or bad) cryptographic practices - it's not a guide on "Testing for Weak Encryption" as the title suggests.

Most of it seems to assume full access to source code - because there's no real detail on how you would check any of this from a blackbox perspective (which is generally pretty hard to do for most cryptographic issues). There's also some stuff that's not really relevant (not using CBC mode ciphers with SSH is good advice, but does it belong in the WSTG?

From what I've seen, WSTG generally assumes that we don't have access source code - in which case this guide would need a significant rewrite to focus on thes tuff that you can actually test for without it, and maybe a pointer to the relevant cheatsheet and ASVS sections for people who do have access?

It should probably also be renamed from "encryption" to "cryptography", unless we're going to split out signatures, hashing, etc into their own guides.

[ThunderSon]

I was contemplating those thoughts yesterday.

@kingthorin would it be safe to just move forward with the guide being "You are testing an application without additional information or knowledge"?
I am with this being transferred to other projects. We do cover TLS implementation over HTTP in another section, we cover oracle padding (I'm pretty sure it's old now as we didn't update it yet ...). We cover as well sensitive data that isn't protected.

I believe providing this content to another project would be fitting with the direction we're headed.

[kingthorin]

Hmmm I'm not sure we should limit it to "black-box". Though either way wouldn't this still be applicable?

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 30 days. To give everyone a chance to contribute, we are releasing it to new contributors.

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 90 days. To give everyone a chance to contribute, we are releasing it to new contributors.

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 90 days. To give everyone a chance to contribute, we are releasing it to new contributors.