we would like to step-up our credit card security on our web server.
Currently we are using AES which is a Symmetric-key algorithm.
we are not too happy, since if compromised the thief will have access to the decryption key.
We are thinking of switching to asymmetric cryptography (Public-key cryptography) so the decryption key will not be stored on this web server. but it seems to me that this type of encryption are not as secure as the symmetric one.
Q1: Does it make sense 2 combine the 2?
I would do as follows.
on web-server
Encrypt credit card with symmetric encryption Encrypt it again with
asymmetric encryption - public key
in Secure environment.
Decrypt w/ asymmetric encryption - public key
Decrypt w/ symmetric encryption
Q2: is it indeed true that asymmetric cryptography is less secure than Symmetric-key algorithm?
Related
I'm trying to understand the mechanism of encryption used on the web.
One thing is not clear to me at this point:
If I check, for example, google.com certificate, I can see that the public key is 4320 bits long, but Chrome shows that the connection is encrypted using AES_128_GCM, that I would expect to work with 128 bit keys.
What am I missing here?
The 4320 bits in the public key algorithm are used to encrypt the 128 bits in the symmetric key algorithm. The public key establishes a secure channel of communication between two parties who initially don't have any shared key. Think of this as a low bandwidth channel, which isn't very useful due to the computationally expensive nature of the public key algorithm. In practice -- the sole use of this public-key is to communicate a shared key to establish a high bandwidth channel which uses something like AES (which requires both parties to have the same key). The overall process is an example of a hybrid cryptosystem.
The whole process is more involved but here are the basis to answer the question.
The data is encrypted with a symmetric algorythm such as AES, it is fast, secure and can handle any length of data.
The symmetric key is encrypted by an asymetric algorythm sucb as RSA or EC, they are slow and the data length is limited by the key length.
There are many articles on the Internet about HTTPS, it can get quite complicated.
i am trying to encrypt/decrypt some long text with RSA public/private key encryption using cryptopp. I found many examples including the official on http://www.cryptopp.com/wiki/RSA but all of the examples have one problem:
They only allow me to encrypt data that is a bit shorter then the key size.
So the question is: Do i really have to split the data and encrypt block for block myself, or does crypto++ already provide some functions to handle this (like GCM or CFB modes on AES encryption)?
Thanx
Generally you should not encrypt large plaintexts using RSA. You can use RSA-OAEP using the ECB mode of encryption, but that's extremely slow and does not give you any advantages over the more common hybrid encryption modes.
In hybrid encryption modes you simply generate a symmetric data key using a secure random number generator. Generally AES-128 bit will be sufficiently strong. You then encrypt the plaintext using this key, e.g. using AES in CBC mode; you may use a zero-IV and PKCS#7 padding. Finally you encrypt the AES key using RSA-OAEP; use either PKCS#1 v1.5 padding if OAEP cannot be used.
The reverse is obvious, decrypt the AES key, decrypt the ciphertext.
Note that you need at least 11 bytes of padding overhead (not just 1 bit) to subtract from the key size to encrypt using RSA in PKCS#1 v1.5. The padding is part of the security of RSA.
You could add integrity protection by signing and then encrypting your data. You could use AES-GCM as you propose, but note that an attacker may still encrypt any data and send it to the receiver. So AES-GCM would only provide limited integrity protection.
I am trying to use asymmetric encryption to encrypt firmware. The bootloader will decrypt and update the flash. This is on a embedded device with 32 bit CPU executing at 60MHz.
I want to use ECC due to its varies advantages. I am new to encryption and my understanding os ECC as implemented in ECIES is to use ECC for the key generation and use AES for actual data encryption. Due to code and ram size, I cannot support multiple encryption algorithms.
Is there a implementation of ECC that can be used just like AES. All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
Thanks.
I'm not sure that you completely understand what ECIES consists of:
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme
That's quite a bit of work, and it requires a whole lot of primitives, including at least one symmetric primitive, it seems to me. That might as well be AES.
Let's start from the last sentence of the question:
All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
There's some confusion in terminology here. Private keys are used to decrypt (or sign) and public keys are used to encrypt (or verify). If I understand correctly, what you want is for the bootloader to verify a signature on the firmware so that only a firmware that was properly signed by yourself will be accepted by the bootloader.
There are various asymmetric signature schemes which can be used for this purpose, including some which are based on eliptic curve cryptography. For example you could use the OpenSSL implementation of ECDSA (see http://www.openssl.org/docs/crypto/ecdsa.html).
I'm afraid there's not enough information in the question to properly choose the best signature scheme (and possibly an encryption scheme as well if there is a need to keep the firmware secret). In any case, good cryptography is not enough to make a system secure and other considerations such as secure implementation are no less important.
If this is is something that is important for you to protect and that you are worried that hackers may try to break, I would strongly advise procuring the services of a security professional. Using cryptography correctly is a very tricky business that requires a full understanding of the system - otherwise you may find yourself in a situation like this
If you look for "authentication" you have to use asymmetric algorithm like EC, this usually done because if the user or process want to update the "firmware" he should identify him self to the bootloader by his "signature" to check who request this update.
After that is done, the bootloader will load the symmetric key from a secure memory to decrypt what you want to do.
So, you have a symmetric key for encryption (AES), and asymmetric two keys for authentication (=Who are you?).
Note: there is no advantages of EC on 32 bit CPU executing at 60MHz for Encryption, unless your application need asymmetric for Encryption NOT authentication, this happen due to line between the user and bootloader is not secure.
Therefore, you could use bootloader's "public key" to encrypt firmware and the bootloader uses its "private Key" to decrypt it, however, the implementation cost a lot due to the high computing for asymmetric algorithm.
Look for "lightweight cryptography", it is typical for your application.
How does public key encryption work, using a private and public/public key to decrypt/encrypt? What does it mean for the key to be 256 bits? How is it decrypted? Is there a language for writing encryption programs or is any language fine?
In brief:
the data is encrypted using symmetric algorithm and a random symmetric key. Then the random key is encrypted using public asymmetric key. The encrypted random key is stored together with the encrypted data. To decrypt the data one uses private asymmetric key to decrypt the stored random key, then the decrypted random key is used to decrypt the data.
256-bit is the length of the key. However, it has dramatically different meaning for symmetric and asymmetric keys. For symmetric keys 256 bits are a very strong key (you can have even longer keys with AES 384 or AES 512 where the numbers specify the key length the algorithm operates with). For asymmetric algorithms 256 bits is nothing, and comparable strength is 2048 bits.
Public key encryption can be implemented using any language, that supports math operations and arrays. However, doing this is reinventing the wheels. There exists a number of cross-platform libraries for PKI: open-source OpenSSL for C++, BouncyCastle for Java and some more. Our company offers a supported and maintained SecureBlackbox product for .NET, Windows and Linux (MacOS X version to come soon).
Also there's a couple of books about PKI that we recommend to all our users. RSA's guide is an easy reading (but very useful) and the second book goes into deeper details.
For the first question see http://en.wikipedia.org/wiki/Public-key_cryptography
you can google for more details.
256 bit key means we are using key of length 256. you will understand that after more reading about answer of first question.
Many language have inbuilt or third party api to implement these calls.
I just installed a SSL certificate. This certificate is encrypted with 2048 bit encryption.
However, the cypher is 128 bit encryption(or 40, or some other variation depending on the browser.)
It seems that there are two different types of encryption here. The "handshake" encryption of 2048 and the "over the wire" encryption of some magnitude smaller.
Do I have this right in theory? Can anyone explain it better?
I have been all over the Google and cannot find a clear explanation of the difference between the two.
There is a good entry in Wikipedia.
You are right, there are two kinds of encryption going on. The first one is asymmetric encryption or public key encryption - this is the one with the larger key. The second type is symmetric encryption with the smaller key.
The first type of encryption (asymmetric - larger key) is used to negotiate what type of symmetric encryption the client and the server will use. They'll also exchange the session key that they'll use. This is the handshake process and this is encrpyted using the asymmetric encryption
The session key is basically the key that they'll use when sending the real data, encrypted by whatever type they've decided on the handshake process. This is the symmetric encryption part.
It is true that symmetric encryption typically uses much fewer bits for its key length. The reason is because symmetric encryption is much stronger at a given number of bits.
Asymmetric encryption (where each side has a different key) is much harder to pull off. It is more computationally intensive and therefore only used for the handshake portion or for encrypting a symmetric key that the rest of the message uses.