I'm trying to use public key crypto to sign and later verify a file. The file is a simple plaintext file that contains user information for authoring purposes.
I tried different sites for a C implementation of a public key crypto algorithm but I haven't found anything. A lot of sites point to using certificates (x.509, etc) but that is way beyond what I need. I am just looking for a way to generate and public and private keys and use a relatively well known algorithm to sign and verify a file.
Any pointers to a pure C implementation out there? The focus is on code that I can reuse and not external libs. The main problem being that I don't want to have to link against a full lib and its dependencies in order to have a very basic public key system.
Thanks.
OpenSSL is a very good package. You can just use the crypto library portion, which provides basic RSA implementations. That might be in line with what you are looking for.
Cryptlib is another alternative that could work for you. It has some strange licensing issues though, so consider those depending on how you will be using it.
Crypto++ is a set of different crypto technologies, and includes RSA, so you might try that.
Finally, RSA is not terribly complex to implement, so you could even implement it yourself using GMP, which provides the necessary mathematical functions you would need.
You may want to look at the well-respected, debugged, and tested OpenSSL libraries. Although OpenSSL is primarily for SSL/TLS networking, it contains extremely good implementations of many cryptographic protocols, which are often used by themselves for general cryptography.
Hope this helps!
DJ Bernstein's curve25519 lets you create public/private key pairs. It does not have functions for signing, but you should be able to figure that part out with not too much hassle.
Update: In the mean time, there's also Ed25519 which already has the signature generation stuff figured out, without you having to jump through hoops. Same author, same availability of software (also e.g. "Donna" implementation and python binding), same ease of use, comparable speed.
The original implementation as well as the "Donna" implementation are both available under very liberal licenses.
You need to compile one file and call exactly one function to generate a key pair, and it's very fast. No obscure requirements for the public key. All one ever needs for some "cheap, fast, easy public key crypto".
I think that there was an answer[1] that fitted your question on :: Small RSA or DSA lib without dependencies
You may find LibTomCrypt useful. It's written in C, supports RSA and
DSA (along with a host of other algorithms), and is public domain
software. You can read about its features here: http://libtom.org/?page=features
[1] https://stackoverflow.com/a/1735526/68338 ( courtesy of https://stackoverflow.com/users/33837/emerick-rogul )
The answers on this question contain some interesting links to other libraries.
However, I remember that there exists some reference source code in C for RSA and private key cryptography. I will add a link as soon as I have found it ;-)
EDIT
I just found "this link" (http://www.hackchina.com/en/cont/93068 - open on your own risk) - not sure about the source and details of that code. But, however, in the past the link to the original RSA reference implementation was contained somewhere in OpenSSL source or its documentation. Which is based on cryptsoft.com's library. I am sure the source can still be found somewhere on www.rsa.com/rsalabs/ - but I could not find it, and I am running out of time for now. Good luck ;-)
Related
I am using musl: https://www.musl-libc.org
If i browse the repository i can see that there are a bunch of crypt related source files (including crypt_sha256.c).
The problem is that there are no header files for them. How am i supposed to use them?
These are the symbols from the lib on my system:
I could also not find any code samples from google how to use the SHA-256 features of musl.
Thanks!
You are correct, that the three functions
sha256_init()
sha256_update()
sha256_sum()
are indeed generic SHA256 hash functions.
Unfortunately, these symbols are not exported publically, but only used internally to generate a salted password hash of the form $5$0rXgD0/KkyyT0$5PPj3bke0vPxsMDlSXzBz2D3TFNahLrXSs7.elU3u2/
For that reason, no public header files for use of these functions are provided. Only the higher-level function crypt_sha256() is exported.
Why they decided to not export the generic interface can only be speculated about, at least I could not find an explanation for that.
That's not generic SHA-256 message digest algorithm but a specific algorithm used by the crypt(3) password hashing function. See the documentation for that function on how it is used.
As Ctx wrote and commented about not knowing the reason for, these functions are not exported. I can fill in that reason.
Generally, musl does not unilaterally invent new interfaces that will almost surely end up differing in subtle ways from similar interfaces other libc providers end up inventing. We are in the process of launching a cross-libc collaboration group less formal than the POSIX standardization process that might make it reasonable to offer some interfaces like this in the future, and that might eventually funnel some of the consensus that emerges upstream to POSIX.
Short of that, anyone wanting to use these implementations is welcome to copy the code and use it under the terms of the license. They're small, self-contained, and permissively-licensed, and by using them this way you don't lock in the signature for any external interface boundary. As usual with cryptographic code, though, you should be careful of any risk of side channels leaking secrets. As used in musl I don't believe that's an issue, but I haven't analyzed other possible uses, and it might be safer to pick an implementation designed for use in arbitrary cryptographic settings.
I´m searching for a way to encrypt my C source files. That way, I can handle it to some project partners. I don´t want them to see my code but I want them to use the functions I implemented so they can flash it on a microcontroller.
Is it even possible to encrypt a source file so J-Link can flash it?
I got told to look up for DLL but I don´t know if a DLL would help in this situation.
For software, I use Dave v4 as IDE and FreeRTOS as firmware. For Hardware I use a XMC4700 Relax Kit.
DLLs won't help,
because your platform (presumably) lacks a dynamic loader. It might be possible to create one, but it doesn't worth the trouble, because you can just
ship the object files.
For that to work, you need a copy of your partner's compiler. Compile your sources exactly as they'd do it (with the same compiler options), and ship the resulting object files along with the headers needed to use it.
This appears to be an XY problem. You want to protect your intellectual property, and you think you can use encryption to do that. You asked about encryption, when you should have asked about protecting your intellectual property.
Encryption isn't very useful for protecting intellectual property. If your clients machine can decrypt the code to run it then your client can decrypt the code. If your client can't decrypt the code the client can't run it. Either way, problems are introduced...
The solution to your problem is the legal system. Use that to protect your intellectual property, instead.
I'm looking for a library that allows me to authenticate data sent to embedded modules. Due to the hardware constraints, it needs to be of small footprint (both code and memory wise) and yet have security comparable to RSA-1024.
The requirements are as follows
Verification on embedded modules (custom CPUs, with only a C89 compiler available)
Signing and verification in Windows (C/C++ code)
Signing in Java (some data needs to be generated via a webpage, so Java would be a big perk)
I would very much like to not have to implement a PKCS #1 v1.5/PSS-like system myself, but I haven't been able to find any good libraries that match the above requirements. Open source would be nice, but commercial solutions are of equal interest. Note that I need access to the C-code, since it has to be recompiled for the custom CPUs.
NaCl looks promising, but it seems to be in development still.
I've had a look at OpenSSL, but it does a lot more than digital signatures and stripping out just the signature verification code was non-trivial.
Am I looking at it the wrong way?
I tried implementing SHA+RSA first, but I wasn't sure if the padding step was correct (which means that it probably wasn't secure), so I decided to post here instead for help.
EDIT: Clarification, only the verification part have the tough constraints on it. Signature and key generation will run on normal PCs.
Take a look at mbed TLS (formerly known as PolarSSL):
mbed TLS (formerly known as PolarSSL) makes it trivially easy for developers to include cryptographic and SSL/TLS capabilities in their (embedded) products, facilitating this functionality with a minimal coding footprint.
How can implement such a kind of solution is related to CPU and memory architecture that we have available, therefore would have to tell me more about your system. The first way would be to develop this on the cloud. Another alternative would be SCL. Also, you can found some answers on Small RSA or DSA lib without dependencies
I've got a project and a part of it is incorporating encryption into a FAT file system.
The goal of the project is not the encryption, so I'm free to use open-source pre-done libraries.
Ideally what I'm after is a C library which uses RSA, that already has the methods for computing keys and encrypting/decrypting files.
You might want to check out NaCl (pronounced as "salt"), especially since this is for an embedded system.
It has CPU-specific tunings and doesn't require any dynamic memory allocation.
As for licensing, the page (linked above) says "All of the NaCl software is in the public domain".
Regarding library - check Cryptlib . It has dual license and includes quite a lot of functionality.
However, capability to encrypt files right depends on how you write the data and how you expect to do encryption.
Streaming encryption for streams with random access (i.e. when you need to encrypt-decrypt file data on the fly when it's written or read) is not a trivial task and requires certain knowledge of cryptography to employ correct encryption mode and do this right.
On the other hand if you have a file and want it encrypted, CryptLib has PKCS7/CMS implementation to do the job.
You might want to give blowfish a try. It's royalty free and there are several open source C implementations. It was created by Bruce Schneier. Here is an article about using it with embedded systems.
Assume you have a function read_key and normally it does some stuff. You someone should be able to replace it with his function read_key_myfunction and it does other stuff.
The general approach would of course be to build an array and register function pointers or using simple switch statements (or both).
But my target is a bit broader: People should be able to write their C-stuff and NOT interfere with my code and it should still register. Of course, I tell them which interface to implement.
What they now basically do is program a library for my software which I dynamically load based on a configuration option. Think of it like OpenSSLs engines: Anyone can write their own engine, compile it as a dll/so and distribute it. They don't need to modify (or know) OpenSSLs code, as long as they stick to the defined interface.
I just want the same (it will in the end be a wrapper for OpenSSL engine functions) for my program.
A colleague suggested I should use the same function in every file and load the libraries dynamically. This sounds like a good solution to me, but I am not quite satisfied since I don't see OpenSSL using any non-engine-specific function in their engine-code.
If some things are unclear here is my specific example:
I am extending a program called sscep which implements a protocol for automatic certificate renewal. A lot of cryptography should take place in HSMs in the future (and right now it should take place within the Windows Key Management (which is accessed by the capi-engine from OpenSSL)).
While OpenSSL already serves a generic interface, there is some stuff I need to do beforehand and it depends on the engine used. I also want to open the possibility for everyone else to extend it quickly without having to dig into my code (like I had from the person before me).
If anyone has any idea, it would be greatly appreciated to see some kind of guideline. Thanks in advance.
What you are describing is commonly called a plugin architecture/plugin framework. You need to combine cross-platform dlopen/LoadLibrary functionality with some logic for registering and performing lookup of exported functions. You should be able to find examples on how to do this on the internet.