I wrote a simple cross-platform utility to verify GPG signatures using the gpgme. However gpgme doesn't work very well on windows and on other platforms (e.g. osx) it requires GnuPG command line utilities installed which is a pretty heavy dependency. I looked into other openpgp libraries as well such as netgpg but these are even less portable (it really has to build with mingw-w64).
Would it be possible to implement a standalone tool to verify GPG signature using only standard libraries like openssl and zlib? From what I understand openpgp consists of standard ciphers and hash functions. What is the part that makes this so difficult that there are no good C libraries out there to do this?
OpenSSL does not implement the OpenPGP format and is not compatible. Use an OpenPGP implementation like GnuPG, Bouncycastle (framework available for Java/C#) or others (OpenPGP.js for JavaScript, and there's a Go library).
While OpenPGP uses standard cryptographic digest and encryption algorithms, it has a different message format and especially uses its own CFB mode variant. You'd have to implement both a parser for the OpenPGP message format and get compatible with the OpenPGP CFB mode (if you want to support encryption), and finally pass the results to OpenSSL for the actual cryptography.
Finally, supporting the whole web of trust concept including the full OpenPGP specification is a broad task and has a variety of issues to consider ([1], [2], ...). In the unix world, people seem to be happy enough with GnuPG and GPGME, which are deeply tested and analyzed for even very advanced security issues (for example, this side channel attack). New implementations are most likely vulnerable to similar problems already solved for GnuPG.
Related
I am using MD5 for checksums. My software is FIPS 140-2 compliant and it doesn't throw any error / exception when I use MD5 for checksum. Where can I find a documentation which says FIPS 140-2 allows using MD5 for checksum.
Update:
Software as in the product for which I work. We have java running in strict FIPS mode and our application is deployed in tomcat. We calculate the MD5 checksum of all the downloadable artifacts and display it in our Administrative Console for the users to verify the artifacts after downloading.
FIPS 140-2 doesn't specify MD5 as an allowed cryptographic algorithm. MD5 is extremely weak and totally insecure, and thus it is not suitable for use in applications which require cryptographic security.
If you are using MD5 as a generic checksum or hash function without cryptographic needs, then that is not within the scope of FIPS 140-2. However, you are better off using a simpler and faster algorithm like CRC64 or another simple hash function. There really is no good reason to use MD5 for any purpose these days.
However, neither of those are suitable for cryptographic purposes. If you need a hash function for cryptographic purposes, you should use one of the SHA-2 or SHA-3 functions for FIPS compliance, or additionally BLAKE2 if you don't need FIPS compliance.
I'm currently working on a prototype. I need RSA Encryption at the Linux Kernel level,although from my research, it seems that the Linux Kernel only supports signature verification. When I look through the code in rsa.c and rsa_helper.c, it seems that there is a rsa global struct that is set to static that has function pointers with variable names: encrypt and decrypt.
Also, there is not a lot of documentation on the asymmetric API. The tcrypto.c does not even test any of the asymmetric crypto API. This seems to be a huge limitation. I am aware that asymmetric encryption is not as fast as symmetric encryption, but I need it for my prototype.
Hopefully,I will not need to roll my own RSA encryption/decryption routines, because this would be a major set back.
Yes, the Linux Kernel supports RSA Encryption/Decryption.
Thanks to some comments I decided to dig a little bit deeper into the Kernel Source. This page is sort of helpful. It unfortunately doesn't require any code samples.
If you would like some code samples, then you can take a look at testmgr.c under the crypto directory. It contains a comprehensive list of supported algorithms in the code.
Can boringssl work on ARMv8 bare metal platform? I tried build boringssl with aarch64-elf-gcc, but it refused to build.
If it does, any porting guide or suggestions?
Probably not out of the box. But you should probably not even try using it, mainly because, according to Google itself, it is not intended for general use.
This is never good to be on your own when using a library, more specifically a cryptographic one. This is usually synonym for no bug fixes, no support, no user forums among other things.
You could rather consider a library that was designed for this purpose, such as mbedtls (formerly known as PolarSSL).
It is being used on a wide range of systems, from bare-metal systems (FreeRTOS) to Linux (The Hiawhata web server does use it for example).
Update: Even if support for Armv8-a hardware crypto extensions is needed, you could still reuse BoringSSL Armv8-a optimized routines (ISC license) or the Cavium armv8_crypto library (BSD license), to replace mbedtls (Apache 2.0 lisense) equivalent routines: cryptographic functions usually have clean and small interfaces.
From my experience, this may still be faster than porting a library targeting a general purpose operating system if your target is a bare-metal one, but you ultimately have to evaluate the costs for both options in your specific case.
My guess would be that there is far less work involved for adding support for Armv8-a crypto extensions to mbedtls using already existing, supported code under the proper license, than attempting to strip-down openssl or boringssl for use on a bare-metal target.
There is a very good piece of documentation explaining how to add support for hardware-accelerated crypto to mbedtls here, this may help you evaluating your options.
Are there any OpenSSL engines that do everything in software and store the secret keys in a file (possibly even in plaintext)?
Perhaps this can somehow be achieved with OpenSSL alone?
The purpose of this is to test whether a piece of software interfaces correctly with the engine API, without having any hardware.
It is assumed that at a later point in time, when an HSM is acquired - it would work with the software right away (provided that the HSM vendor offers an OpenSSL engine).
I am not sure whether pure software implementation of OpenSSL engine exists but you could try engine_pkcs11 with SoftHSM.
I have a low volume (<500 PDFs/year) application for automated digital-signing of PDF files using iText in Java on Linux.
I've got iText adding a digital signature to PDFs using my SSL certificate. Is this a valid method to prove the PDF was generated by my domain (e.g. server)? Can it be used somehow to get the green checkmarks showing "trust" in Adobe Reader?
If not, I should use a certificate intended for PDFs (e.g. not my SSL certificate), so that the little green checkmarks indicating "trust" appear naturally when the user opens the PDF document.
The book http://itextpdf.com/book/digitalsignatures does a great job introducing this topic to me (I have very little experience in this area).
The book talks about a SafeNet Luna device (an HSM), but's it is much too expensive. I only require a minimal solution, and the Luna has a lot of bells and whistles. The Luna PCIe device is less expensive, but I don't require any features other than providing a certificate I can use to sign. Also, the USB-based SafeNet iKey device seems only to be marketed to Windows devices. Has anyone got iKey working with Linux? Is it even possible? Do other companies offer USB based devices that work on Linux?
I'm looking for a minimal solution for serving automated digitally signed PDFs on a Linux box. I'm sure a lot of small businesses have similar needs. I'm just trying to tap into existing knowledge out there. How do people solve this problem?
The solutions I see for automating this process assume large corporations using Adobe Live Cycle, and priced accordingly (see for example: https://www.globalsign.com/pdf-signing/compare-pdf-signing.html). But small businesses need to automate things too.
Ideally someone would sell a certificate similar to the SSL certificates, but for PDF files. Is there such a thing?
Is hardware (of some sort) a requirement (seems so)? If hardware is a requirement, are there any minimal solutions out there (e.g. with limited functionality other than enabling digital signing)?
Hoping someone can help me see the forest from the trees. What's the conventional wisdom?
Regarding signing with your SSL certificate: in a future iText version, we make require that the key-usage of the certificate indicates that the certificate can be used for non-repudiation. For now, we make checking the key-usage the responsibility for the developer, but in a perfect world, you should only sign with certificates suited for non-repudiation, and your SSL certificate probably doesn't allow this.
Regarding the green check mark: unless you can ask the consumers of your PDFs to add the root certificate of your certificate to the list of trusted identities, you'll always need a public/private key stored on hardware to get a green check mark.
Regarding the price of an HSM / USB key. USB keys are much cheaper, but usually they are meant for manual use (usually they have a limit of signing only once every second). I think that GlobalSign has a flavor of keys that work on Linux. As for HSMs, one of our customers told us that he bought one from Utimaco because it was less expensive (but I don't know what budget he had or spent).
No price info, but maybe a good read for inspiration: http://www.opendnssec.org/wp-content/uploads/2011/01/A-Review-of-Hardware-Security-Modules-Fall-2010.pdf