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.
Related
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.
Does anybody know what exactly is protected by IP? Searching the RSA website for RC4 does not find any match.
From the PDF 1.7 documentation:
Note: RC4 is a copyrighted, proprietary algorithm of RSA Security,
Inc. Adobe Systems has licensed this algorithm for use in its Acrobat
products. Independent software vendors may be required to license RC4
to develop software that encrypts or decrypts PDF documents. For
further information, visit the RSA Web site at <
http://www.rsasecurity.com > or send e-mail to <
products#rsasecurity.com >.
RC4 was reverse engineered. Read the Wikipedia page. Implement. Copyright doesn't apply to cleanroom reverse engineering and the hard half has already been done for you.
Normally I'd tell you RC4 is not to be used but today you have an actual use case.
I am new for developing CryptoAPI with signing certificate in VB. My old system uses emvtool.exe to sign the certificate with Luna CA3 and HSM. For example, get keys, format data and sign the certificate. I read all the files about CryptoAPI and CSR workflow. I need to redesign the format data and signing parts. I am totally lost on how to use CryptoAPI instead of emvtool.exe.
thanks for any help.
I'm not familiar with the CryptoAPI in Windows, however, I believe if you have the Luna driver installed on the machine, you most likely have a "Crypto Provider" listed in Windows for the HSM. This is useful in interfacing with the HSM when performing some Windows crypto operations. So I'd dig into the CryptoAPI and whenever there's mention of a parameter for the crypto provider, use the Luna's provider.
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.
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.