Sign/verify, encrypt/decrypt regular files

[stokito]

I wish to sign a contract doc file with a certificate issued to me by a government. Also I think it would be great to encrypt files for myself with my own self signed certificate. Currently the KSE allows only to sign JAR files. Can we extend it's functionality for a regular files? There is a jsign project that allows to sign executables but again nothing about signing regular files. I created a feature request for this with a proposition to use the KSE as a GUI.

[kaikramer]

There have been similar feature requests like that before. While I am not opposed to adding such features to KSE (and have actually already considered it in the past), I see some significant issues with that:

1. In general they are a bit out-of-scope for a keystore management tool. The feature of signing jars exists in KSE mainly because the CLI tool jarsigner is a companion of keytool.
2. As you already partially found out, there is not a single way to sign files. There are different ways from Microsoft, Google and Apple to sign executables for Windows, Android and macOS. Then there is the signing of documents in certain formats (for example PDF and XML documents and probably many more). Again these are individual signature formats and they require either big libraries or a massive implementation effort. Then there is PKCS#7/CMS which seems to be what you need, but in a detached way, not embedded into the PKCS#7 data. Maybe with certain attributes? Other users might need other attributes in the PKCS#7 data. There are lots of options and variety for signing data.
3. For encryption the situation is similar. However, most people probably would simply create an encrypted ZIP file.
4. A big question for me in general is: For how many KSE users will a new feature actually be useful? For example there has been a feature request to add APK signing. Probably nobody would ever use this because normally these are either signed by the IDE or in a build pipeline.
5. And finally: Features like this often need active maintenance over a long period of time. If a 3rd-party library is used, its API might change over time. It might be discontinued, have bugs or security issues or an update suddenly requires a Java version that is incompatible with KSE. All of these have already happened in the past and sometimes require a significant amount of effort and time to handle.

To summarize these points: Feature bloat is bad and should be avoided.

Now to your specific requirements: For a PKCS#7 signature you don't need a special library, this is already available in Bouncy Castle and should be pretty easy to implement in KSE. However, I will only accept this feature request if it is useful for a wider range of people, so if you can list more use cases, that would be very beneficial.

[kaikramer]

Related: #96 and #162

[gdmeunier]

Hello, I wanted to chime in because although PKCS7 detached signatures will do better for signing a .doc contract I still think that Keystore Explorer would greatly benefit from being able to sign arbitrary data.

If @stokito is really given a .doc file, it might be better to just generate a .p7s detached signature.

If it was a .docx file, then it could be signed with a DOCX Signer utility. This would generate a context-aware signature that displays correctly in Office programs.

But I still think that Keystore Explorer would benefit from being able to sign arbitrary data (the way OpenSSL does it).

In PHP it's what the openssl_sign() function generates, it's a bare RSA/DSA/etc signature that isn't tied to any file format.

It's also a base64 output and I found it used in other Java-based programs. It could also be used for digitally signing text & letting recipients verify it in KSE.

The Keystore manager then also becomes a good data signer & a data integrity verifier. If you can add a file / text signing dialog that generates PHP-like OpenSSL output, then it would be useful.

More details: OpenSSL signatures aren't like PGP, and while we have many PGP signing tools, there are fewer ones that generate pure OpenSSL signatures.

If an app requires being provided with OpenSSL signatures, then you can't give it a '----- BEGIN PGP SIGNED MESSAGE -----' signature, it wants a barebone base64 output instead.

[kaikramer]

@gdmeunier Thanks for your input. These are some interesting points.

Having just the raw signature as output/input and therefore being independent of any formats, is certainly not a bad idea, but it has its own issues:

• If you have a file with such a signature in it, how do you know which signature algorithm was used? You have to know this in order to verify the signature. PKCS#7 includes an algorithm identifier for that. Letting the user select the algorithm from a list might work in some cases, but I am afraid in many cases users might not know or try to verify signatures in other formats.
• Having "just a bunch of bytes" without any structure or additional meta data is in general a bit problematic. You simply cannot detect the content. If KSE expects PKCS#7 signatures as input and the user presents a signature in another format, KSE can at least react with a proper error message.
• The points above are probably the reasons why not many tools create or process raw signatures. With OpenSSL CLI it is possible of course, but I don't know any other tools. And BTW OpenSSL CLI also supports PKCS#7 signatures (with openssl cms). Interoperability with a wide range of other tools seems worthwhile.

Also, everyone who has requested this feature so far wanted a different format, this alone shows how difficult it is to add this feature in a way that is useful for a larger group of users.

But I certainly agree that KSE should rather get a generic data signing feature (PKCS#7 or raw) than something specific like PDF, DOCX or PGP.

[gdmeunier]

@kaikramer Thanks for your reply.

Actually with raw signatures you have to feed OpenSSL with the public key so that it cans verify the signature.

Perhaps PKCS#7 is better due to being able to embed the x509 certificate that was used to create the signature, and there are PKCS#7 signature viewers for Windows.

This would make it more user-friendly for electronic documents. But at the same time, we do also have PKCS#7 signer utilities for Windows too.