I would like to generate a certificate with only a few information to get a very small certificate, maybe just the Version, Serial Number, Issuer, Validaty, Public Key and the signature.
I am asking this because the certificate I have just generated using openssl has about 900Bytes which is too much for the purposes I want.
I want a certificate to use with ecdsa 256 with nistp256.
Why do not you consider some good compression algorithm to reduce the size?
Or you can reduce the key size to reduce the overall size. As far as I know, you can generate minimal certificate with some basic information (Version, Serial Number, Issuer, Subject, Validity, public key and signature are required). You can omit the extensions and keep these fields too small.
To reduce the size, you can reduce the size of these information. However, version (as governed by standard), serial number, issuer (governed by issuer authority) and validity are not in your control. Signature is also depends on signer's public key which may not be in your control (unless you are signing yourself or using self-signed certificate) as it depends on size of the signing private key and hashing algorithm.
Only things in your control are subject (you may on your choice can keep it very small) and public key (you can choose size and algorithm but that may compromise the security or issuer may not allow).
Over and above, you can use some compression if that can reduce the size of certificate significantly.
Related
As part of an assignment I need to make an algorithm that takes 2 files as input, one containing a plaintext and one containing a ciphertext. Considering the encryption model is hardcoded/known, and is a symmetric encryption, is there a way to use openSSL to compute the key used to encrypt the provided plaintext into the provided ciphertext?
For convenience i used 5 paragraphs of Lorem Ipsum as a plaintext, and blowfish as the cipher.
The openSSL documentation and Google have proved less than useful.
Thank you!
No, the ability to do that would pretty much defeat the entire purpose of cryptography. There might be tools that can do that sort of thing with trivial systems (Caesar cipher for example) but if keys could be computed in reasonable times for current cryptosystems they would be broken.
What you are looking at is a "Known Plaintext Attack": if the attacker knows both the ciphertext and the plaintext, can the key be found?
All good modern ciphers, including Blowfish, are designed to resist this attack. Hence, as has been said, the answer to your question is, "No, you can't find the key."
No you can't.
Not for the blowfish algorithm.
The reason for that is however not that any encryption scheme would be broken if it were possible to derive the key from a pair of plain text and cipher, even if it is easy to do so.
The rest of this answer is to explain that.
There is at least one encryption scheme which is secure in spite of allowing to derive the key. It is the one-time-pad encryption scheme, which happens to be the only known truly secure encryption scheme, for being proveably unbreakable.
The point is that deriving the key of one message only breaks an encryption scheme, if the knowing the key of one message allows decryption of all future messages. This in turn is only applicable, if the same key is reused.
The specialty of the one-time-pad encryption is
a) each key is used for only a single message and never again
(this is why it is called "pad", referring to a notepad with many keys, from which the sheet with a used key is easily taken away and destroyed)
b) the key is as long as the message
(otherwise deriving the key for a part of the cipher with a partial known plain text would allow decrypting the rest of the message)
With those attributes, encrypting even with the humble XOR is unbreakable, each bit in the message corresponding to its own dedicated bit in the key. This is also as fast as de-/encryption gets and never increases the message length.
There is of course a huge disadvantage to the one-time-pad encryption, namely key logistics. Using this encryption is hardly ever applicable, because of the need to provide the receiver of a message with many large keys (or better a very long key which can be used partially for any size of message) and to do so beforehand.
This is the reason for the one-time-pad encryption not being used in spite of the fact that it is safer and faster than all used others and at least as size-efficient.
Other encryption schemes are considered practically secure, otherwise they would of course not be used.
It is however necessary to increase the key sizes in parallel with any noticable progress of crypto-analysis. There is no mathmatical proof that any other algorithm is underivable (meaning it is impossible to derive the key from a plain-cipher-pair). No math expert accepts "I cannot think of any way to do that." proof for something being impossible. On top of that, new technologies could reduce the time for key derivation, or for finding plain text without key, to a fraction, spelling sudden doom to commonly used keylengths.
The symmetry or asymmetry of the algorithm is irrelevant by the way. Both kinds can be derivable or not.
Only the keysize in relation to message length is important. Even with the one-time-pad encryption, a short key (message length being a multiple of key length)
has to be used more than once. If the first part of a cipherhas a known plain text and allows to derive the key, reusing it allows to find the unknown plain for the rest of the message.
This is also true for block cipher schemes, which change the key for each block, but still allow finding the new key with the knowledge of the previous key, if it is the same. Hybrid schemes which use one (possibly asymmetric) main key to create multiple (usually symmetric) block keys which cannot be derived from each other are, for the sake of this answer, considered derivable if the main key can be derived. There is of course no widely used algorithm for which this is true.
For any scheme, the risk of being derivable increases with the ration of the number of bits in key to the number of bits in the message. The more pairs of cipher bits and plain bits relate to each key bit, the more information is available for analysis. For a one to one relation, restricting the information of one plain-cipher pair to that single pair is possible.
Because of this any derivable encryption requires a key length equal to message length.
In reverse, this means that only non-derivable encryptions can have short keys. And having short keys is of course an advantage, especially if key length implies processing duration. Most encryption schemes take longer with longer keys. The one-time-pad however is equally fast for any key length.
So any algorithm with easy key logistics (no need to agree on huge amounts of keybits beforehand) will be non-derivable. Also any algorithm with acceptable speed will be non-derivable.
Both is true for any widely used algorithm, including blowfish.
It is however not true for all algorithms, especially not for the only truly safe one, the one-time-pad encryption (XOR).
So the answer to your specific question is indeed:
You can't with blowfish and most algorithms you probably think of. But ...
I am not able to generate RSA key pair inside VSS through macros. I am in need of script to gerate key inside and compute Public CA and do RSA computation inside. Please help in this regard.
As far as I know, it is not possible to generate a RSA keypair inside VSS (v4.0).
You might want to try generating a keypair using the embedded openssl and then store it into the key slot (beware that there are probably some constraints on some key slots (modulus length,exponent length) -- check your documentation).
Beware that the RSACOMP operation does only a raw RSA computation (modular exponentiation) and you will have to handle the padding stuff yourself (and correctly).
A much simpler alternative is to generate the keypair outside (HSM?) and inject it securely to the terminal (I do not understand your use case -- but some certificate for this keypair could be injected as well)
Good luck!
Currently I am investigating https://github.com/orlp/ed25519 , and it has example for signing but how to use it for encrypting/decrypting data? Thanks
Assuming you want to send a message to Alice who has the public key A.
Generate a new ephemeral key pair e, E
Compute the shared DH secret between e and A using the ed25519_key_exchange function.
Use some kind of of KDF of that secret. In the simplest case a hash.
Use the value derived in step 3 as key in a symmetric algorithm
NaCl's crypto_box works almost like this. The main differences are that it uses Montgomery form public keys and uses HSalsa20 as hash in step 3.
Some people don't feel comfortable with using the same keypair for signing and encryption. Use at your own risk. If you don't need this key reuse, I'd recommend LibSodium as an alternative.
You don't. ED25519 is a public-key signature system, not an encryption system. Trying to use it for a purpose it was not designed for is likely to introduce security vulnerabilities.
I'm developing simple software that does aes256-cbc encryption of a file. I'm using GNU/Linux and libgcrypt-1.5.0. The IV is randomly generated with the OpenSSL rand function and the IV is stored before the ciphertext in the output file. I'm using the PKCS#7 padding method.
Now I am in doubt about how to proceed:
It is better to use sha256 repeated 50,000 times of the inputed password to encrypt the file, or it is better to use the password given by the user?
If I want to check the correctness of the inputed password, I have to store it into the encrypted file (obviously encrypted). Is it correct to do this?
Use PBKDF2 to derive a key as indiv suggested.
Use PBKDF2 with a different salt to derive an authentication key and append a MAC to your encrypted data (after encryption is more secure than before encryption). Verify the MAC in order to check whether the password is correct or not, and that the data has not been tampered with. If you are unsure when choosing a MAC, use HMAC with SHA-512 (assuming you are using AES-256 as per your question).
Instead of using PBKDF2 twice with different paddings, you can use a single invocation of PBKDF2 to generate both the encryption and the authentication keys at the same time, by generating a key of the combined size of your encryption key and authentication key in one go.
Note that depending on the padding for deciding whether the key was good can result in CBC padding oracle attacks. For file encryption such attacks might not be applicable, depending on the exact circumstances, but it seems prudent practice to use a proper MAC for data authentication anyway, since you also want to prevent bit flipping attacks and other malicious modifications to your data.
Neither choice is correct. You need to use an algorithm made for deriving a key from a password, like PBKDF2. See the function gcry_kdf_derive.
1.It is better to use sha256 repeated 50,000 times of the inputed password to encrypt the file, or it is better to use the password given by the user?
You never use the "raw" password directly as a key. The key needs to be strectched in something hardened against brute forcing attacks. Look at the String-to-Key (S2K) stuff, or a Password Based Key Derivation Function (PBKDF) with a memory-hard hash like scrypt.
2.If I want to check the correctness of the inputed password, I have to store it into the encrypted file (obviously encrypted). Is it correct to do this?
No. You use an authenticated encryption mode like GCM. Authenticated encryption modes are specially built for the task and provide both confidentiality and authenticity.
Under the password, the encrypted file will verify or it won't. Don't concern yourself with the reason why. Otherwise, you're setting up an oracle which may undo everything from Step 1 (which may or may not be applicable here).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm implementing a small application in C, which I would like to sell as shareware for a reasonable price later on. It will start of with a 30-day trial, which I am already quite certain of how to implement it.
The problem I have, though, is that I am not quite sure how to implement the product key verification. What I have in mind is that the customer can sign up on my webpage (after trying the product for a while), pay for the product, and get a product key in the form of aaaaa-bbbbb-ccccc-ddddd-eeeee via e-mail (or maybe available via his profile on my website). No problem so far. He/She then drops the key in the appropriate key fields in my app and boom the app is registered.
From what I could gather so far, people either recommend AES or RSA for this. To be honest, I in another direction in college (not cryptography) and the one cryptography class I took was some time ago. But from what I remember, AES is a symmetric encryption algorithm, which would mean that I would only have one key for encryption and decryption, right? How could I then generate thousands of product keys and still validate them in my app (which by the way won't require internet access....so no checking back with a server)?
So I guess RSA would be the way to go? But doesn't RSA produce pretty long keys (at least longer than the required 25 characters from above)?
In another thread I read that some products won't even use encryption for the product key generation/verification, but instead just employ some checks like "add the 2. and the 17. character and that should total to x".
What's the fastest, easiest and most secure way to go here? :-) Code samples would be sugar!
Regards,
Sebastian
P.S.: Oh...and please don't tell me how my key can and will be cracked at some point.....I know about that, which is primarily why I don't want to spend a lot of time with this issue, but at the same time not make it too easy for the occasional cracker.
Symmetric algorithms are limited, in that any novice cracker with a disassembler can find your key (or the algorithm used to generate one) and make a "keygen".
For this reason, asymmetric cryptology is the way to go. The basic premise is something like this:
When the user purchases a license from you, you collect certain identifying details about the user and/or their environment (typically, this is just a full name; sometimes a company, too).
You make a 128-bit MD5 hash of this information.
Using a 128-bit Elliptic Curve crypto, encrypt this hash using the private key on the server.
The 128-bit cipher text can be represented to the user as a 25-character string consisting of letters and digits (plus separating dashes for readability). Notice that 26 letters + 10 digits = 36 discrete values, and that 36^25 > 2^128.
The user types this product key into your registration dialog. The client software converts it back to a 128-bit number (16 bytes), decrypts that using the public key of your EC crypto, and compares the result to an MD5 hash of the user's personal information, which must match what was used for registration.
This is just the basic idea, of course. For more details and source code, see Product Keys Based on Elliptic Curve Cryptography.
Life is simpler if you simply purchase a solution.
http://www.kagi.com/kagisolutions/index.php
Kagi allows you to collect payments and they help you manage the keys.
A guy has blogged about how he handled the question of registration numbers. One of his blog entries is Generating Unique Registration Numbers.
Yes, RSA and AES are two very different things:
RSA is public key cryptography, involving a public key and a private key, and is fairly slow. The primary use is to set up a secure exchange of a symmetric encryption session key.
AES is symmetric encryption, which is fast and secure.
Since your app does not communicate over public channels and the use of cryptography is limited to product activation/registration you'll want to go with a symmetric cipher. The benefits of public key ciphers is in key management, which you will be handling on your web site or through email.
Note that you do not have to distribute the same key for every customer. You could generate a hash of some of the registration info and XOR it with something else (a fixed session key, perhaps). Send that to the customer, and the program could generate the same hash and XOR will the key you sent to produce the original fixed key.
Dealing with cryptography is not something to be done lightly. As you mention, you expect this to be cracked. If you're doing your own this will almost certainly happen. You can still use your own implementation to "keep honest people honest," but realize that's as far as you'll get. If you need something stronger then you should purchase a solution after doing thorough research on the solutions.
You can check out this Code Project article. It describes an implementation of a a software key based on the MAC address of the machine where the software is executed. The method is not ideal, as the auteur himself admits, and it is a little bit different from what you are looking for, but maybe it can help you.