Is it possible to encrypt a file in Java with AES algorithm of Block size 128 bits and key size 256 characters(bytes) ?
As per references
the key size can be of maximum 256 bits or 32 characters.
I have a requirement to do with 256 characters, is it possible ?
AES has one block size of 128-bits and three key sizes of 128, 192 & 256 bits.
If you have a 256 characters, characters depending on the encoding can be more than 1 byte, you can use a key derivation method such as PBKDF2 (Password Based Key Derivation Function 2) to derive a key from the characters.
See the comment to the question.
Related
I am using AES-256 encryption with CFB mode. I have to use 32 byte key.
But I am little bit confused about the initialization vector.
How many bytes of initialization vector should be used with AES-256 ?
Is it 16 bytes or 32 bytes ?
Any code example will be appreciated.
TL;DR: AES in CFB mode requires a unique (but not necessarily randomized) IV of 16 bytes.
The size of the IV depends on the mode, but typically it is the same size as the block size, which for AES is always 16 bytes. There are modes that differ from this, notably GCM mode which has a default size of 12 bytes but can take any sized IV - although keeping to the default is highly recommended.
The old school modes such as CBC and CFB however simply require an IV of the same size as the block size. Even CTR commonly requires 16 bytes, although in principle the IV can be any size less than 16, in which case it is (again, commonly) right padded with zero valued bytes. Note that CTR is often initialized with an initial counter value which means you must make sure that the counter is not repeated yourself.
The block size of AES is 16 bytes, whatever the key size. Saying that you have AES-256 and a key of 32 bytes is superfluous information. For AES-256 the key size must be 256 bits or 32 bytes.
The IV for CFB mode - as stated earlier - must always be 16 bytes as AES is a 128 bit block cipher. AES is restricted with regards to the block size compared with the Rijndael cipher. Rijndael may be configured with different block sizes.
I'm learning about RSA cryptography, so I must understand about ke length.
Here, I found explanation about key length means.
There said:
When we say a "1024-bit RSA key", we mean that the modulus has length
1024 bits, i.e. is an integer greater than 2^1023 but lower than 2^1024.
Such an integer could be encoded as a sequence of 1024 bits, i.e. 128
bytes.
What I've got from there, 1024 bit key means the key has 1024 binary number sequence int it.
We all know, 1 byte = 8 bits. So, 1024 bits = 128 bytes. Okay, it's in binary. How about in character?
According to ASCII binary code here, each character has 8 bits binary number. So, in my mind, if key has 1024 bit length, it means the key contains of 1024/8 = 128 characters. So, I created a java program to generate prime number that has 128 numbers length. So far, the program works well.
But again, I rethought the real meaning of RSA 1024-bit. So, I googled and found this. I tested it and I get that the bit length of public key modulus is 1024. But, the public key has 309 numbers length.
Now, I really confuse.
My question: what's the real means of 1024-bit key length in RSA? As I thought or as I found here?
The example saves the key as Object Stream, which is java serialized object stream, it has some metainfo about javatypes and special format to encode binary data. To see genuine size of the number try "pub.getModulus().bitLength()". For me it prints 1024.
The important parameter is "greater than 2^1023". This means, the raw RSA encryption algorithm can represent arbitrary numbers from 0 to 2^2013-1, but not numbers greater or equal to the modulus. By Key Design the Modulus is the product of two different prime numbers and will never meet a power of 2, like 2^1024.
So the maximum number of bits you can represent is key-length-1, which are floor((key length -1)/8) complete bytes; in the best case you loose one bit of the key length.
As the PKCS-standard for mapping text to numbers considers complete bytes, you always need one more byte for representing the equivalent number; for a 1024-bit-key the maximum length of text to be encoded is 127 bytes.
The other number "309 bytes" comes from the X.509-Standard for storing/exchanging keys, a dialect of the ASN.1-Protocol; it includes RSA-type information, the modulus and the public exponent.
I have implemented an AES (CBC) algorithm in Java crypto with PKS5Padding. I noticed that for a input string size of 128 bytes; size of the cyphered text is 144 bytes. Is this normal? For my understanding AES algo should not pad this string since it is a multiplication of 16.
PKCS#7/PKCS#5 padding is always applied. Check the Wikipedia page. If your 16 byte aligned data would end with a byte 01 and you would remove the padding, then you would have one less byte of plaintext. So for AES 1 to 16 bytes are added, and having a multiple of the block size is therefore the worst situation instead of the best.
is it possible to create a secret key using AES but with a given length and it should cointain only 0-9a-Z?
I just need a 32 characters key as a SecretKey spec :( for AES256 encryption/deceryption
is it possible to create a secret key using AES but with a given length and it should cointain only 0-9a-Z?
It is. By generating an AES secret key value, and then making sure that the ascii value of each character is within the bounds of 0-8 (48 - 57) or a-z (97-122).. Where it isn't, simply ammend the value to be within the range.
But..
This would make a wildly unsafe key. By limiting your values so heavily, you are effectively limiting the amount of possible combinations. Whereas normally, it is 2^256 possible combinations (considered secure at this point), you're dimishing that to much less possible combinations... which isn't secure.
Also, the above algorithm I suggested would make an awful lot of repeating values. You'd be comparing differences, and then ammending until that difference is 0.. which means:
For any value < the desired value.
round value to desired value.
Let desired value = 100;
Let any value = 50;
50 --> 100;
Let any value = 60;
60 --> 100;
And ontop of that..
A Brute Force Attack will usually start out by testing aaaa... x 256. Then (aaaa x 255) 1. What I mean is, a brute force usually starts with alpha numeric characters. You're just making your key ripe for a cracking there.
AND ONTOP OF THAT..
An AES key is defined as 128, 192 or 256 bits. That is the standard. You can't change the length. What you can do is look into the Rijndael, which is what AES was before it became the standard. This can accept a wider range of key values.
AND ONTOP OF THAT
An AES key is generated by the key schedule, the way it is for a reason. It is designed to be cryptographically resistant to cryptanalysis. By messing with that, you compromise the security of the entire algorithm, thus making it pretty pointless implementing the cryptographic standard, when you're going to mess with the output.
I CANT FIND A BIGGER FONT
You want your output to be 32 characters long. In ASCII, that means 8 bits per character. Or 32 x 8 = 256. Well.. AES's recommended mode is 256 bits, so you're in luck. You can use a hashing algorithm which will generate values that should be within the bounds of a-z0-9.
A AES-256 key is 256 bit long, and would be too big to store in 32 characters (0-9a-Z).
However, if you relax your requirements a bit by extending your character set with 2 more characters (to 64 in total) - then you can store 6 bits of the key in one character - which then allows you to store a 192 bit AES key in the 32 characters.
Below code would create a 32 character base64 encoded string (0-9a-Z+/) of a 192 bit AES key:
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(192);
SecretKey key = keyGen.generateKey();
String keyBase64 = Base64.encode(key.getEncoded());
How would I be able to determine the encryption of a key (AES256 or 3DES 256)...Since both keys will be 32 characters (8 bits per char * 32 char)=256 bits and Mime encoded.
Example
MQAyAEgAOgA5ADUAMwA3AD8AQgBFAD4A --->AES256 key
g1EOWGFb+JjCZ7BbH2RergtKUtDfXrNb --->3DES key
The AES keys were made in Openssl while the 3DES ones were made using Java with the following Apis.
javax.crypto.Cipher;
javax.crypto.KeyGenerator;
javax.crypto.SecretKey;
javax.crypto.SecretKeyFactory;
javax.crypto.spec.DESedeKeySpec;
javax.crypto.spec.IvParameterSpec;
First of all, there is no such thing as 3DES 256. 3DES has a key size of 128 or 192 bits, of which 112 and 168 bits are effectively used. Note that the security margin of 3DES is even lower.
AES on the other hand can be used with 128, 192 and 256 bits, all of which are used.
Now base 64 (not SMIME, that's a higher level protocol) has 6 bits per character (not excluding spurious bits at the end). If I check your keys both of them are 192 bit in size, so that won't help you distinguish the keys. You can use the Apache Codec library to decode base 64 strings.
However, your 3DES key - the second one - seems to use odd parity bytes for the 3 single DES keys. That can be used to distinguish the keys from each other. Note that this is not foolproof, a randomly generated AES key may have the parity bits set correctly by chance alone. However, the chance of that happening is somewhere around the order of 2^24.
It is possible to use the method DESedeKeySpec.isParityAdjusted(byte[] key, int offset) to check if the parity is correctly set. It is required to decode the base 64 string first of course.
Note that sometimes 3DES keys are distributed without having the parity set correctly. In your case, you need to use the KeyFactory to generate the keys otherwise the parity may not be set.
Another way of checking if the key is of the correct type is to decrypt some known plaintext/ciphertext/secretkey pair using both algorithms.