The question is why signatureValue is so big if it is based on hashes?
Suppose Signature Algorithm is sha256RSA.
Shouldn't it be smaller according following steps:
Calculate SHA256 hash from tbsCertificate. Output => 256 bits.
Sign 256 bits hash with RSA private key. Output => 256 bits?
But if you see the size of the signatureValue, it might have 2048, 4096, [bigger?] bits.
Signature size doesn't depend on hashing algorithm used to hash signed data. It depends on key size only.
The RSA signature is based on modular exponentiation, i.e. sig = m ^ d mod N, where:
m is message to be signed
d private exponent (its size is N / 2, i.e. 1024 bits for RSA 2048).
N modulus
sig signature value
For such a calculation the final result is the remainder of the m ^ d result divided by the modulus (roughly, RSA key size). The m and d are quite large values and when you power one by another, the value will be huge and won't fit even modulus length, this is why last mod operation is used. And you can see, there is no term such as "hash". Sometimes (when very small values are used), resulting value size can be less than modulus size. In such cases, signature value is padded to match the modulus length.
From raw signature you can infer RSA key size, but can't infer the hash algorithm embedded in signature, this is why signature contains asymmetric algorithm and hash name, such as sha256RSA, otherwise, you will have to store hash algorithm somewhere in message. Since the combination (asymmetric algorithm and hash algorithm) is finite and quite small, it was good enough to assign unique OIDs to such combinations.
Related
I'm learning some basic cryptography related programming and I'm now learning diffie-hellman-merkle key exchange. I was watching a video by Computerphile where they explain the mathematics of it.
In the video, they said that you should use n that is 2000 or 4000 bits long. I've seen this key length be discussed as bits in several other places, like with AES. But I don't understand what "length in bits" means. What does it mean to have a key that is 2000 bits long, so if I need to write a program that creates or uses keys that are of certain length, what would I need to do?
If you need to write a program that creates keys of a certain length, you pass the desired key length to the program. You need to know in which unit the length is expressed (for example, some interfaces might require bytes rather than bits), but you usually don't need to know what the key length means under the hood.
The concrete meaning of the key length depends on the cryptographic scheme, and for some schemes, there can be an ambiguity as to what the “key length” is. It's typically one of three things:
The length of a string that is associated with the algorithm, such as a key.
A number n such that an integer parameter of the algorithm is picked between 2^(n-1) and (2^n)-1.
A number n such that an integer parameter of the algorithm is picked between 1 (or some other small bound) and (2^n)-1.
Both of the last two cases are called “n-bit numbers”. In cryptography, “n-bit number” sometimes means a number that can be written with n digits in base 2, and sometimes a number which requires exactly n digits in base 2. In other words, “n-bit number” sometimes means a number whose bit-size is exactly n, and sometimes a number whose bit-size is at most n. You have to check the exact requirement in the description of each cryptographic scheme.
Depending on the cryptographic scheme, a different number is conventionally chosen as the “key length”. For any specific scheme, a larger key length is harder to break, but you can't compare key lengths between different schemes.
For most symmetric schemes, the key is a randomly generated string (each bit of the string has an independent ½ chance of being 0 or 1), and the length is the number of bits of the string. For example, AES-128 is AES using a 128-bit (16-byte) key. There is only one exception worth mentioning: DES keys are expressed as 64-bit strings, but only 56 of those bits are random (the other 8 are calculated from the random 56), and so DES is sometimes considered to have a “56-bit” key length and sometimes a “64-bit” key length.
For Diffie-Hellman, the key length n is the exact size of the group (conventionally written p). Both the private key and the public key are numbers between 1 and p, so they're at-most n-bit numbers. This is as simple as it goes in terms of key length for asymmetric cryptography.
For RSA, the key length n is the exact size of the modulus, which is one part of the public key (the public key is a pair of numbers: the modulus and the public exponent). For example, 4096-bit RSA means that the modulus is between 2^4095 and 2^4096-1. The private key is also an n-bit number, but in the at-most sense.
For DSA, there are two numbers that can be called the key length, because the private key and the public key are chosen in intervals that have different sizes. The public key length is the size of the larger prime p; the public key is a number between 2 and p-2. The private key length is the size of the smaller prime q; the private key is a number between 1 and q-1.
For elliptic curve cryptography, the domain parameters of the algorithm are called a curve: a set of points, and a parametrization of this set of points. A private key is a parameter value that designates a point on the curve, and a public key is a pair of integers that are the coordinates of a point on the curve. In general, since the private key and the public key live in different mathematical spaces, there are two numbers that could be called the “key size”. A private key is a number between 1 and n-1 for some m-bit number n, and a public key is a point with two coordinates, each of which are between 0 and q for some ℓ-bit number q. In general, m and ℓ don't have to be equal. However, n and q are usually close (if they aren't, it's a waste of performance for a given security level), and so m and ℓ are usually equal and can be called the “key length” without ambiguity.
Every bit can be either 1 or 0. It's the basic unit in the digital world. As you may know, all that is digital end up being either 1 or 0. Each 1 and 0 is a bit.
So something of length n bits means that it has n 1s and 0s.
When using the openssl_encrypt() function in PHP to encrypt a string with AES-256-CBC as the encryption method:
$encrypted = openssl_encrypt($data, "AES-256-CBC", $key, 0, $iv);
I tried different string lengths for $data, and the resulting length of $encrypted will increase when $data reaches a multiple of 16 bytes. But it seems the growth is not steady.
Is there a general formula that relates the length of $data and $encrypted?
Let me quote from https://stackoverflow.com/a/3717552/2393787
With CBC mode, the input data must have a length multiple of the block length, so it is customary to add PKCS#5 padding: if the block length is n, then at least 1 byte is added, at most n, such that the total size is a multiple of n, and the last added bytes (possibly all of them) have numerical value k where k is the number of added bytes. Upon decryption, it suffices to look at the last decrypted byte to recover k and thus know how many padding bytes must be ultimately removed.
Hence, with CBC mode and AES, assuming PKCS#5 padding, if the input data has length d then the encrypted length is (d + 16) & ~15. I am using C-like notation here; in plain words, the length is between d+1 and d+16, and multiple of 16.
This states, that the length of your encrypted data can't be predicted with CBC. You should consired moving to another mode.
I've some clear text which I want to encrypt using RSA_PKCS_V21 (using PolarSSL library). The problem is that I need to know size of cipher text before executing the algorithm (for dynamic memory allocation purpose).
I know RSA key size & clear text length.
I also want to know the limitation on input clear text length.
Any idea?
Just check the RSA PKCS#1 v2.1 standard, chapter 7.2:
RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M)
Input:
(n, e) recipient's RSA public key (k denotes the length in octets
of the modulus n)
M message to be encrypted, an octet string of length mLen,
where mLen <= k - 11
So the input depends on the key size. k is that key size but in octets. So for a 1024 bit key you have 1024 / 8 - 11 = 117 bytes as maximum plain text.
Note that above is the maximum size for RSA with PKCS#1 v1.5 padding. For the newer OAEP padding the following can be found in chapter 7.1:
RSAES-OAEP-ENCRYPT ((n, e), M, L)
...
Input:
(n, e) recipient's RSA public key (k denotes the length in octets
of the RSA modulus n)
M message to be encrypted, an octet string of length mLen,
where mLen <= k - 2hLen - 2
L optional label to be associated with the message; the
default value for L, if L is not provided, is the empty
string
Where hLen is the output size of the hash function used for the mask generation function. If the default SHA-1 hash function is used then the maximum size of the message is k - 42 (as the output size of SHA-1 is 20 bytes, and 2 * 20 + 2 = 42).
Normally a randomly generated secret key is encrypted instead of the message. Then the message is encrypted with that secret key. This allows almost infinitely long messages, and symmetric crypto - such as AES in CBC mode - is much faster than asymmetric crypto. This combination is called hybrid encryption.
The output size for RSA encryption or signature generation with any padding is identical to the size of the modulus in bytes (rounded upwards, of course), so for a 1024 bit key you would expect 1024 / 8 = 128 octets / bytes.
Note that the output array of the calculated size may contain leading bytes set to zero; this should be considered normal.
It appears they are both encryption algorithms that require public and private keys. Why would I pick one versus the other to provide encryption in my client server application?
Check AVA's answer below.
My old answer seems wrong
Referring, https://web.archive.org/web/20140212143556/http://courses.cs.tamu.edu:80/pooch/665_spring2008/Australian-sec-2006/less19.html
RSA
RSA encryption and decryption are commutative
hence it may be used directly as a digital signature scheme
given an RSA scheme {(e,R), (d,p,q)}
to sign a message M, compute:
S = M power d (mod R)
to verify a signature, compute:
M = S power e(mod R) = M power e.d(mod R) = M(mod R)
RSA can be used both for encryption and digital signatures,
simply by reversing the order in which the exponents are used:
the secret exponent (d) to create the signature, the public exponent (e)
for anyone to verify the signature. Everything else is identical.
DSA (Digital Signature Algorithm)
DSA is a variant on the ElGamal and Schnorr algorithms.
It creates a 320 bit signature, but with 512-1024 bit security
again rests on difficulty of computing discrete logarithms
has been quite widely accepted.
DSA Key Generation
firstly shared global public key values (p,q,g) are chosen:
choose a large prime p = 2 power L
where L= 512 to 1024 bits and is a multiple of 64
choose q, a 160 bit prime factor of p-1
choose g = h power (p-1)/q
for any h<p-1, h(p-1)/q(mod p)>1
then each user chooses a private key and computes their public key:
choose x<q
compute y = g power x(mod p)
DSA key generation is related to, but somewhat more complex than El Gamal.
Mostly because of the use of the secondary 160-bit modulus q used to help
speed up calculations and reduce the size of the resulting signature.
DSA Signature Creation and Verification
to sign a message M
generate random signature key k, k<q
compute
r = (g power k(mod p))(mod q)
s = k-1.SHA(M)+ x.r (mod q)
send signature (r,s) with message
to verify a signature, compute:
w = s-1(mod q)
u1= (SHA(M).w)(mod q)
u2= r.w(mod q)
v = (g power u1.y power u2(mod p))(mod q)
if v=r then the signature is verified
Signature creation is again similar to ElGamal with the use of a
per message temporary signature key k, but doing calc first mod p,
then mod q to reduce the size of the result. Note that the use of
the hash function SHA is explicit here. Verification also consists of
comparing two computations, again being a bit more complex than,
but related to El Gamal.
Note that nearly all the calculations are mod q, and
hence are much faster.
But, In contrast to RSA, DSA can be used only for digital signatures
DSA Security
The presence of a subliminal channel exists in many schemes (any that need a random number to be chosen), not just DSA. It emphasises the need for "system security", not just a good algorithm.
Btw, you cannot encrypt with DSA, only sign. Although they are mathematically equivalent (more or less) you cannot use DSA in practice as an encryption scheme, only as a digital signature scheme.
With reference to man ssh-keygen, the length of a DSA key is restricted to exactly 1024 bit to remain compliant with NIST's FIPS 186-2. Nonetheless, longer DSA keys are theoretically possible; FIPS 186-3 explicitly allows them. Furthermore, security is no longer guaranteed with 1024 bit long RSA or DSA keys.
In conclusion, a 2048 bit RSA key is currently the best choice.
MORE PRECAUTIONS TO TAKE
Establishing a secure SSH connection entails more than selecting safe encryption key pair technology. In view of Edward Snowden's NSA revelations, one has to be even more vigilant than what previously was deemed sufficient.
To name just one example, using a safe key exchange algorithm is equally important. Here is a nice overview of current best SSH hardening practices.
And in addition to the above nice answers.
DSA uses Discrete logarithm.
RSA uses Integer Factorization.
RSA stands for Ron Rivest, Adi Shamir and Leonard Adleman.
I was wondering:
1) if I compute the digest of some datas with SHA-512 => resulting in a hash of 64 bytes
2) and then I sign this hash with RSA-1024 => so a block of 128 bytes, which is bigger than the 64 bytes of the digest
=> does it mean in the end my signed hash will be exactly 128 bytes?
Thanks a lot for any info.
With RSA, as specified by PKCS#1, the data to be signed is first hashed with a hash function, then the result is padded (a more or less complex operation which transforms the hash result into a modular integer), and then the mathematical operation of RSA is applied on that number. The result is a n-bit integer, where n is the length in bits of the "modulus", usually called "the RSA key size". Basically, for RSA-1024, n is 1024. A 1024-bit integer is encoded as 128 bytes, exactly, as per the encoding method described in PKCS#1 (PKCS#1 is very readable and not too long).
Whether a n-bit RSA key can be used to sign data with a hash function which produces outputs of length m depends on the details of the padding. As the name suggests, padding involves adding some extra data around the hash output, hence n must be greater than m, leaving some room for the extra data. A 1024-bit key can be used with SHA-512 (which produces 512-bit strings). You could not use a 640-bit key with SHA-512 (and you would not, anyway, since 640-bit RSA keys can be broken -- albeit not trivially).