I know about length of some small encrypted strings as: 160, 196 ..
What determines the size?
The size in bytes of a single "block" encrypted is the same as the key size, which is the same as the size of the modulus. The private exponent is normally about the same size, but may be smaller. The public exponent can be up to to the key size in size, but is normally much smaller to allow for more efficient encryption or verification. Most of the time it is the fourth number of Fermat, 65537.
Note that this is the size in bits of the encrypted data. The plain data must be padded. PKCS#1 v1.5 uses at most the key size - 11 bytes padding for the plain text. It is certainly smart to keep a higher margin though, say 19 bytes padding minimum (a 16 byte random instead of a 8 byte random for padding).
For this reason, and because it is expensive to perform RSA encryption/decryption, RSA is mostly used in combination with a symmetric primitive such as AES - in the case of AES a random AES symmetric secret key is encrypted instead of the plain text. That key is then used to encrypt the plain text.
Related
I am trying to learn to use PBKDF2 hash functions for storing passwords in the database. I have a rough draft of the procedure that I'll be using to generate the hashed function. But while I am creating the table in PL/SQL Developer which will hold the generated hashed password, what should I declare the data type for the encrypted password variable?
It might be a lame question but I'm trying to learn online. It would be a huge help if I can get links for further study as well. thank you. please help
The first link, as always, is Thomas Pornin's canonical answer to How to securely hash passwords.
Storage in the database
The hash can be stored in BINARY format for the least transformations and smallest number of bytes; see below for sizes.
Alternately, store it in a CHAR after converting to hex, which costs a transformation and double the bytes of the BINARY size
Alternatively, store it in a CHAR after converting to Base64, which costs a transformation and 4/3rds the number of bytes of BINARY size plus padding
i.e. PBKDF2-HMAC-SHA-512 where all 64 bytes of output are used would be
BINARY(64) as binary
CHAR(128) as hex
CHAR(88) as Base64
The number of iterations should be stored in an INT, so it can be trivially increased later
The salt, which must be a per-user, cryptographically random value, can be stored in a BINARY format for the smallest number of bytes, and should be at least 12, and preferably 16-24 bytes long.
i.e. for a 16 byte binary salt
BINARY(16) as binary
CHAR(32) as hex
CHAR(24) as Base64
Optionally a password hash algorithm version as a small INT type
i.e. 1 for PBKDF2-HMAC-SHA-512, and then later if you change to BCrypt, 2 for BCrypt, etc.
Normal PBKDF2 considerations
Consider using PBKDF2-HMAC-SHA-512, as SHA-512 in particular has 64-bit operations that reduce the advantage most GPU based attackers have over you as of early 2016.
Use a high (hundreds of thousands or high tens of thousands) of iterations.
Don't ask for a larger number of PBKDF2 output bytes than the native hash function supports
SHA-512 <= 64 bytes
SHA-384 <= 48 bytes
SHA-256 <= 32 bytes
SHA-224 <= 28 bytes
MD5 <= 20 bytes
I am generating a cipher text using RSA algorithm and it's working fine. But the thing is, I the cipher text generated is very high.
For example:
Plain text : 249488213
gets generated to,
Cipher text : 94489103D862769B7AE21EA42C2D400A584D0F919BBCAE2450AD1BE57EAC64E4A2F75FAB9F8FA25BCBC12AAAE58F43CCB071DC002332FF4C736F4DA96A36C3ED
which is too large for my use-case as it increase the file size of my plain text file to approx 2.5 times greater.
So my concern is, can we reduce the length of cipher text to some minimum length (despite of key size we use), or is there any other asymmetric algorithm that can help me achieve this.
Any help is appreciated. Thanks.
RSA encryption is described as
c = m^e mod N,
where c is a cipher text, m is an original message, e is public exponent (typically 65537) and N is public modulus.
Thus, c is always smaller than N, but in most of the cases of the same order as it. Sure you can select N and m to get a small c, but this will obviously lead to make encryption weaker, and you need a special key for every message.
Probably, the same problem will be with other assymetric cryptosystems. Shorter cipher text is easier to recover. But you can use AES, which can produce in counter mode a cipher text of the same size as an original message. Which reveals size of the message to the attacker.
I'm using the PyCrypto implementation of AES and I'm trying to encrypt some text (24 bytes) using a 24 byte key.
aes_ecb = AES.new('\x00'*24, AES.MODE_ECB)
aes_ecb.encrypt("123456"*4)
I get this surprising error ValueError: Input strings must be a multiple of 16 in length
So why is it that my input must be a multiple of 16? It would make more sense to me that the input string length must be a multiple of my key size, because this would allow nice bitwise operations between the key and blocks of plaintext.
AES is a block cipher. Quote from the Wikipedia page: “a block cipher is a deterministic algorithm operating on fixed-length groups of bits”.
AES can only work with blocks of 128 bits (that is, 16 chars, as you noticed).
If your input can have lengths others than a multiple of 128, depending on your application, you may have to be extremely careful how you handle padding.
Just want to add info about mods of operations
Yes, AES is a 128-bit (16-byte) block cipher with multiple possible key length (128, 192, 256), but the cause of this text padding limitation (and error msg) is ECB mode of operation. ECB is the simplest of the encryption modes. I don't know your goals, so will just skip the part that it doesn't provide serious message confidentiality.
CBC and CTR are more common and usually appropriate to use and in CTR mode you don't need 128-bit message length.
There is also ciphertext stealing (CTS) method for ECB and CBC modes.
Method of using a block cipher mode of operation that allows for
processing of messages that are not evenly divisible into blocks
without resulting in any expansion of the ciphertext, at the cost of
slightly increased complexity
But Ciphertext stealing for ECB mode requires the plaintext to be longer than one 128-bit block.
Because the block size is 16 bytes, the way to handle this is to add padding when encrypting.
What is the $key_length in PBKDF2
It says that it will be derived from the input, but I see people using key_lengths of 256 and greater, but when I enter 256 as a key_length the output is 512 characters. Is this intentional? Can I safely use 64 as the key_length so the output is 128 characters long?
$key_length is the number of output bytes that you desire from PBKDF2. (Note that if key_length is more than the number of output bytes of the hash algorithm, the process is repeated twice, slowing down that hashing perhaps more than you desire. SHA256 gives 32 bytes of output, for example, so asking for 33 bytes will take roughly twice as long as asking for 32.)
The doubling of the length that you mention is because the code converts the output bytes to hexadecimal (i.e. 2 characters per 1 byte) unless you specify $raw_output = true. The test vectors included specify $raw_output = false, since hexadecimal is simply easier to work with and post online. Depending on how you are storing the data in your application, you can decide if you want to store the results as hex, base64, or just raw binary data.
In the IETF specification of Password-Based Cryptography Specification Version 2.0 the key length is defined as
"intended length in octets of the derived key, a positive integer, at most
(2^32 - 1) * hLen" Here hLen denotes the length in octets of the pseudorandom function output. For further details on pbkdf2 you can refer How to store passwords securely with PBKDF2
I am using a AES algorithm in my application for encrypting plain text. I am trying to use a key which is a six digit number. But as per the AES spec, the key should be minimum sixteen bytes in length. I am planning to append leading zeros to my six digit number to make it a 16 byte and then use this as a key.
Would it have any security implications ? I mean will it make my ciphertext more prone to attacks.
Please help.
You should use a key derivation function, in particular PBKDF2 is state-of-the-art in obtaining an AES key from a password or PIN.
In particular, PBKDF2 makes more difficult to perform a key search because it:
randomizes the key, therefore making precomputed password dictionaries useless;
increases the computational cost of testing each candidate password increasing the total time required to find a key.
As an additional remark, I would say that 6 digits correspond roughly to 16 bits of password entropy, which are definitely too few. Increase your password length.