Legal restrictions of using RC4 decoder - pdf

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.

Related

Does Linux Kernel Support RSA Encryption/Decryption?

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.

How to use CryptoAPI to sign certificate?

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.

How to verify GPG signature with OpenSSL

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.

OpenSSL file based pseudo-engine

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.

iText: what type of certificates do people use to automate PDF signing on Linux?

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