I have a 1200 bit key which i would like to use for encrypting data.Is there any encryption algorithm i could use that uses a large key?
The performance of the algorithm does not have to be really good but as long as it uses the entire 1200 bit key,it is good enough.
Use a key derivation function such as PBKDF2 to create a symmetric key from the 1200 bit key.
Then use AES to encrypt the data.
Related
I'm developing an encryption protocol where I have to create an AES key in CTR mode. I decided to keep the key length 128 bits in length, as shorter key size would mean less computing power for mobile devices.
Now, to create this key, I use PBKDF2, which allows me to set its certain parameters like hashing function and iteration number, as it derives a key using an initial information, such as a password, which is what I have. As SHA-1 broken, I wanted to use SHA-256 for the key derivation function's key hashing but I don't understand if it is possible. As I want key to be 128 bits, and SHA-256 is producing 256 bits, does PBKDF2 capable of doing that?
AES-256 is not much slower than AES-128, keysetup is slightly slower, and every block only needs 4 more rounds (11 to 15). So it's about 40% slower at most, and with modern phones having dedicated AES-instruction sets probably even less.
PBKDF2 can output almost any size key, and mostly HMAC-SHA1 or HMAC-SHA256 (not SHA1 or SHA256 directly, but most API's only accept a hash function as parameter and do the HMAC implicitly) is used as the building block "random function". But either one can produce 256, 128 or 10000 byte keys (not that you need that large a key anyway). With HMAC-SHA256 it's equally cheap or expensive to derive a 256 or 128 bit key (the latter is a truncated version of the former, but that's no issue); it's the same work. With HMAC-SHA1 (which is as secure as HMAC-SHA256 for PBKDF2) it's a bit more the work to get a 256 bit key, as 256 is more than the digest size.
So use AES-256 and PBKDF2-(HMAC)-SHA256, should be no performance issue.
First of all the AES-256 is not so slow compared to AES-128. See from Cryptography
CPU overhead (+20% for a 192-bit key, +40% for a 256-bit key:
The PBKDF2's output size is equal to the used PRF function, in your case it is a hash function as SHA-256. Therefore the output will be in 256-bit size.
The PBKDF2's function requires a dkLen parameter - desired Key Lenght.
PBKDF2(PRF, Password, Salt, c, dkLen)
When you put 128 into this parameter you will get a 128-bit. The output is the substring of the full 256-bit output. You will get first 128-bit.
You can see it from implementations as here
Can we assume that same encryption key is used to encrypt data if encrypted data are same?
For example, plain text is 'This is sample'.
First time we use 3DES algorithm and encryption key to encrypt it. Encrypted data became 'MNBVCXZ'.
Second time again, we use 3DES algorithm and encryption key to encrypt it. Encrypted data became 'MNBVCXZ'.
My questions are:
Can I assume static encryption key is used in this encryption process?
How many keys can be used to encrypt data using 3DES algorithm?
Can I assume static encryption key is used in this encryption process?
Yes, if you perform the encryption yourself (with a very high probability), no if an adversary can perform the encryption and the plaintext/ciphertext is relatively small.
As 3DES does indeed have 2^168 possible keys and 2^64 possible blocks, it should be obvious that some keys will encrypt a single plaintext to the same ciphertext. Finding such a pair of keys requires about 2^32 calculations on average (because of the birthday paradox).
If the plaintext is larger (requires more than one block encrypt) then the chance of finding a different key that produces the same ciphertext quickly will go to zero.
If one of the keys is preset it will take about 2^64 calculations to find another key. And - for the same reason - there is only a chance of 1 / 2^64 to use two keys that unfortunately produce the same ciphertext for a specific plaintext.
If you want to make the calculations yourself, more information here on the crypto site.
How many keys can be used to encrypt data using 3DES algorithm?
2^168 if you consider the full set of possible keys, i.e. you allow DES-ABC keys. These keys are encoded as 192 bits including parity. This would include DES-ABA and DES-AAA keys (the latter is equivalent to single DES).
2^112 if you consider only DES-ABA keys. These keys are encoded as 128 bits including parity. This would include single DES.
I need to use RSA encryption in a environment where byte size of the keys are important.
I don't want to risk security breaking, so I wondered if you could have one person transmit his key first using (2048 bit) and then have the other transmit his key of size (256bit) encrypted with the other guy's key. And if this would still provide a secure scheme?
PS: I realize 256 bit would increase from the encryption and you can ignore the man-in-middle problem.
TL;DR: Does keeping public key secret allow for a smaller key size?
Typically one would use RSA and other asymmetric algorithms specifically for the purpose of exchanging keys. The security of RSA has to do with factoring large primes, which is why their key sizes are typically so much longer than symmetric keys for algorithms such as AES. What you don't want to do is reduce the RSA key size in your scheme. So if what you're doing is creating a 256 bit AES key and then using AES thereafter for encryption I think the security scheme will work. Public key cryptography is much slower than symmetric encryption therefore for performance and other reasons you don't want to use RSA.
As to your question regarding keeping the public key secret, I think that goes against what RSA is meant for. A public key is meant to be public.
The implementation can have failings as well, for example SSL 3 was found to have a padding oracle vulnerability in 2014. I would suggest you use a standard implementation like TLS rather than trying to make your own protocol. Secure protocols are typically the most difficult problems in cryptography.
I read some white paper about RSA encryption. I find this statement. but I can't understood why?
Statment is The time for RSA encryption and Decryption depends on the key size, but does not depend on the size and content of input data, if this statment right meaningly wehen encrypt 1000 byte , 10000 byte same time for encrypt and decrypt?
The time is always the same because the input length is always the same.
The plain text is padded to the size of the RSA modulus. If the plain text is too long, you cannot encrypt it with RSA. Of course, you can split your plain text up and encrypt each chunk with an independent RSA operation, but this isn't how the algorithm was intended to be used.
RSA encryption is best suited as a key transport algorithm. You choose a symmetric key, and use an RSA public key to encrypt it. The symmetric key can be used for encrypting a lot of data with some algorithm like AES. This is much, much faster than using public key cryptography to encrypt and decrypt bulk data.
I'm some newbie of data encryption. I goggling data encryption and mostly found md5 and SHA algorithms.Which technology do you consider to be the best for data storage/security and why?
MD5 and SHA are hash functions, they create fingerprint - fixed-length representation - from the bunch of data. For example, they are extensively used as a way to check consistency of your iso image downloads for many open-source products, but this means you can use them to create fingerprints from any selection of bytes. So they do not encrypt.
If you want to encrypt, you should check for encryption algorithms. The most feasible now I believe is AES (Advanced encryption Standard) if you look for symmetric encryption algorithms (eg. where key for encryption and decryption is the same or easily computed one from another) or RSA if you look for asymmetric (where you have 2 keys - public and private, and compute private key from public is hard task).
If you are about to create digital signatures, you may want to check things like DSA (digital signature algorithm) and ECDSA (DSA over elliptic curves.). Note that asymmetric algorithms work over numbers with extended precision - like 512, 1024, 2048 bits and so on. You need special libraries that can handle such numbers. If you use C++ I can recommend you trying Crypto++. Find something similar for other languages.
I hope this was useful for you.
If your data is password and you want to store it some where then Use MD5 or SHA Hash.
There are two advantages of these.
A hash can not be decrypted to recover old value so your password will never ever will be cracked even if you provide MD5/SHA hash of password to some one :)
A hash of particular string will be always same so you can compare passwords based on Hash.
AES :
Symmetric algorithm so faster
Use with PKCS5Padding and CBC mode
Always store IV
Symmetric so you need same key while you are decrypting encrypted text so you can not at all share keys.
RSA
PKI Infrastructure to exchange Keys
Slow
There are other algorithms also Like DES(Not So Secure), 3DES(Often called Tripple DES- Not enough secure compared to DES)