tshakalekholoane / wardstone Goto Github PK

Is your feature request related to a problem? Please describe.

Storing the keys in containers (usually HashSet) instead of just their identifiers.

Describe the solution you'd like

Derive or implement the Hash trait for keys which will allow them to be stored in exception lists instead of just their identifiers. This is arguably provides better clarity.

Describe alternatives you've considered

Leave things as is. The current solution is probably more efficient albeit negligibly.

Additional context

For example:

Is your feature request related to a problem? Please describe.

For example, standards tend to provide a range of years in which their recommendations are expected to stay relevant. The user can indicate their preference by constructing a Context with the desired year.

The current unit tests only test the default path i.e. minimum security required by a standard in the year 2023.

Describe the solution you'd like

A complete suite would include years prior and after 2023. This is especially important for primitives such as 3TDEA that have a different deprecation schedule than all other primitives in their own class.

Is your feature request related to a problem? Please describe.
when i generate with OpenSSL a key, i want to know if the key is up to certain cryptographic standards

Describe the solution you'd like
the program should take the standard (bsi, fips, another) and a der/pem file and analyze if the keys are up to the requirements of the standard.

Is your feature request related to a problem? Please describe.
It may be the case i expect to have a certain security level measured in bits and wardstone gets to know this somehow. Now i want that my application uses a certain cryptographic primitive, or it uses one which i actually do not see in the haystack. Now this primitive is not good enough for my expected security level, then it would be nice if wardstone could point me to a similar primitive which enables this.

Describe the solution you'd like
if i tell wardstone i want to have 200 Bits of security but i have not seen that AES-192 is chosen as a primitive, then it would be nice, if configured in that way via a parameter (either environment variable or on the stack) that wardstone tells me something like, this is too short for your required length, but there's AES-256 which fullfills that and can be chosen from the NIST standard.

This will not work in all cases and may be to complex to map though.

Describe alternatives you've considered
One alternative is, that wardstone returns all primitives which are better, if a certain condition is set, but this seems overwhelming.

Additional context
We have to see if this is too complex to implement, and if the standards give enough room to actually choose from or if the standards for AES for example actually allow in combination with their other operations (blockmodi e.g.) actually allow this at all.

Working with strings between C and Rust is a bit complicated poses issues with regards to safety. It is avoided where possible.

Is your feature request related to a problem? Please describe.

It might be nice to add colours to the responses i.e., red for failed audits and green for those that pass.

Describe the solution you'd like

Implement the ability to show colour but only if:

• The output is going to an interactive terminal (TTY) and not stdout or stderr.
• The NO_COLOR environment variable is set.
• The TERM environment variable has the value dumb.
• The user passes the option --no-color.
• Optionally, the WARDSTONE_NO_COLOR environment variable is set just in case the user wants to disable colours for just this program.

This should just be for the text output. For JSON, a similar effect can be achieved through piping to the jq command.

Is your feature request related to a problem? Please describe.
When we look at the Github Project we currently do not see what it is about and how it is used or compiled.

Describe the solution you'd like
Please provide a README with a description and how to compile it. Using it will be a bit more complicated, we can add that later.

Additional context
We should also note that this is a GSOC project

Is your feature request related to a problem? Please describe.

The ECRYPT-CSA report specified additional primitives (see commits below) that aren't mentioned in all the other standards and thus do not have corresponding tests in these modules.

Commits:

• cc5919d.
• df0888b.
• 509a212.
• 7381f9a.

Describe the solution you'd like

Write tests for these.

Describe alternatives you've considered

Leave it as is. The return value is the same in all of them given they'll be assessed against an exception list that already specifies primitives that the standard explicitly mentions so the value add seems minimal. Nonetheless it might be a good thing to have.

Is your feature request related to a problem? Please describe.
When we want to see whether certificates or other keys are up to certain standards, we have a library. but we want to see whether existing certificates are compliant or not.
Describe the solution you'd like
Now that we have a library which looks for standard compatibility of cryptographic keys, we want to have a program which

1. showcases the use of the library
2. helps us scanning for the validity of keys according to certain chosen standards.

The solution is a command line program, which should take a certificate and the standard as an input and show whether the key is up to the standard.

The programm shall at one point be able to ingest openpgp keys, x509 certificates and ssh keys. What is implemented at which stage is decided by the software author.

For now we will not implement filewalking but only ingest direct files.

Is your feature request related to a problem? Please describe.

While the RSA-PSS is arguably a better alternative to RSA PKCS#1 v1.5, it might be better to recommend the latter instead given that the latter has better adoption.

Some protocols such as SSH also only specify RSA PKCS#1 v1.5 and so a recommendation to use the RSA-PSS instead would be wrong in this case.

But one also has to be careful since some standards i.e., the BSI, have deprecated the use of RSA PKCS#1 v1.5 (see p. 12 of BSI-TR-02102-2) so special care should be taken to ensure that this is reflected in the logic as well.

Is your feature request related to a problem? Please describe.
I want to know if my ssh private or public keys are up to certain standards

Describe the solution you'd like
the program should take the ssh key and the considered standard and check whether the key size is good enough

Is your feature request related to a problem? Please describe.

Improve coverage by adding integration tests. The cmd crate has test keys that can be used to achieve this.

Describe the solution you'd like

Perhaps using something like assert_cmd or clap's Command::debug_assert.

Describe alternatives you've considered

Writing unit tests that read a key and ensure that it is parsed correctly. This would probably be enough given the individual primitives already have tests in the relevant standards modules.

Is your feature request related to a problem? Please describe.
I have requirements on a few fronts here:

• during development we might want to have automated tests, which should work or fail in all cases. having or using pseudostandards would enable us doing that without adding to much magic.

• later in production people perhaps have the idea of creating their own standards. a pseudostandard which they may be allowed to change locally might ease this pain, even if they have to rebuilt the library. Because we do not want them to fiddle with the real standards.

Describe the solution you'd like
Additionally to having the official standards which should not be changed i want two standards to be introduced.

1. a very trusting one, where the key/securitylevel is 64 bit, so every algorithm out there, even DES and MD5 will be considered okay
2. a very paranoid one which only accepts OCB3, AES-256, SHA3-512 and only postquantum-assymmetric-cryptography-primitives

The first one we can use to include every primitive we have, so we know, even if it has to fail in a certain standard, it would actually work in another one where the security level is low enough. Complementary to it, having good cryptography which will still fail (like AES-256 with GCM for symmetric encryption) if configured that way is easier to test in complicated environments.

Describe alternatives you've considered
for better testing of primitives which should or should not fail we could mock the data structures, but that would generate a pretty big test harness quite fast. with my proposal we perhaps could minimize that a bit.

for custom standards i have no alternative idea.

Is your feature request related to a problem? Please describe.

Process files concurrently or in parallel if this yields a performance increase.

Is your feature request related to a problem? Please describe.

Return the input primitive as a recommendation if the recommended primitive would have the same or similar level of security.

Describe the solution you'd like

For example, currently the user might have a SHA3-256 and assessing its compliance, they might get recommended the SHA256. In most cases this would not be necessary and thus it might be better to return SHA3-256 instead, explicitly encoding that a switch need not be made.

Describe alternatives you've considered

Leave things as is. In most cases the default recommendation is a widely used primitive such as SHA256 that has been around longer and thus might have better hardware and library support than newer primitives (notwithstanding issues around its lack of resistance against length extension attacks in this particular case).

Is your feature request related to a problem? Please describe.

The SSH protocol specifies more public key algorithms than what ssh-keygen can generate.

Describe the solution you'd like

Add test keys for these and ensure that the application can correctly parse them.

cbindgen does not currently allow macro expansion on stable. This would arguably lead to more readable code for enumerating all the supported primitives.