By loading a pre-created .key file that includes an RSA Private Key only I noticed, that it contains the following numbers:
Modulus (private modulus)
Exponent (private exponent)
P (prime exponent)
Q (prime exponent)
DP
DQ
InverseQ
I am saving the key file somewhere, where storage is very small (portable). I though of only saving Modulus and Exponent. I understand P,Q and E are necessary to create modulus and exponent, however:
Question:
What is the purpose in saving all this data to a .key file, when PrivateModulus and PrivateExponent are enought to sign and decrypt messages?
Well, you need the public key Modulus and Exponent for encryption and the private key Modulus and D for decryption and signing.
P and Q are probably just added there for safety, since there is no efficient way to reconstruct them from the other given values. So in case your D gets corrupted, you can reconstruct it or if possibly a special implementation requires them for some Math-tricks to optimize the calculations.
The values of DP, DQ and InverseQ are used by some implementations to calculate RSA using the Chinese Remainder Theorem for speeding up the whole process.
DP = D mod (P - 1)
DQ = D mod (Q - 1)
InverseQ = Q^-1 mod (P - 1)
For more information on how that works, best check out this crpypto.stackexchange-question or the Wikipedia-article.
Related
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.
so we have a private key used to sign requests which are later decrypted using the public key. I was messing around with it and replaced a few characters in it, say changing 'wnoy' to 'xxyy'
I suspected this would essentially change the key and the decryption fail as a result but this wasn't the case. Are the changes simply too small to result in a meaningful change to the key?
Thank you!
Any change to the modulus, exponent or CRT parameters that are used during calculation will result in failure of the algorithm to produce a correct signature or in failure during decryption (most likely producing a padding error).
However, because an RSA private key is not just a single number it is commonly saved in a PKCS#1 defined ASN.1 / DER encoded structure. Now it depends on what you change of this structure if the private key is damaged enough or not. The encoding of this structure (if it is a PEM private key) may also play a role.
Most likely you have changed the public or private exponent while the RSA CRT parameters are being used in the calculation (either the private exponent or CRT parameters are used for the calculations). In that case the calculation will proceed as normal. You would have about 256 bytes that can be changed without causing a problem for a 2048 bit key.
The slower "plain" RSA calculation uses the private exponent, which means that any change to the CRT parameters will go unnoticed (unless the structure doesn't parse anymore). For a 2048 bit key you would very likely have over 5 x 128 bytes that can be changed without causing a problem!
From PKCS#1:
RSAPrivateKey ::= SEQUENCE {
version Version,
modulus INTEGER, -- n
publicExponent INTEGER, -- e
privateExponent INTEGER, -- d
prime1 INTEGER, -- p
prime2 INTEGER, -- q
exponent1 INTEGER, -- d mod (p-1)
exponent2 INTEGER, -- d mod (q-1)
coefficient INTEGER, -- (inverse of q) mod p
otherPrimeInfos OtherPrimeInfos OPTIONAL
}
here the CRT (Chinese Remainder Theorem) parameters are the prime1, prime2, exponent1, exponent2 and finally coefficient parameters.
I'm not learning cryptography yet, and this exercise - in the form it was delivered as a homework, was more of an exercise on reading composite functions and the like. Either way, I took a look at some part of the source code and didn't understand this.
For RSA encryption, the source code manipulated the string in such a way:
Message is being hashed into an integer list. (int1, int2, int3...)
Encrypt int1
Subtract result from int2 ( int2 - e(int1))
Modulo with the modulo key (n)
RSA transform with a key.
However, the RSA decryption method is done by:
1) RSA_transform
2) Result is added
3) Modulo with n
The part that puzzles me about the RSA decryption is the need for modulo after the adding and rsa_transform. If it's needed, shouldnt it be used in reverse order of how the chain of operations was carried out in RSA encryption?
Also, an "invert_modulo" was provided in the source code. I originally believed this to be a key in decrypting the message, but it wasn't so. What could "invert_modulo" be used for?
I cannot understand the first part of your question as the steps to hash the string is not clear also i don't get 3rd part of your encryption step. As for the Second question invert_modulo is the "MODULAR MULTIPLICATIVE INVERSE".
While working with modular airthmetic we always want our answer to be in the integer range 0 to M-1(where M is the number we modulo with) simple operations like addition , multiplication and subtraction are easy to perform : like (a+b) MOD M, it is well defined for the constraints of modular airthmetic.
Problem arises wen we try to divide : (a/b) MOD M
as you can see here a/b may not always always give an integer, therefore (a/b) does not lie in the integer range 0 to M-1. so to overcome this we try to find an inverse of b that we would rather multiply a with, i.e : (a*b_inverse) MOD M.
b_inverse can be defined as : (b*b_inverse) MOD M = 1.
i.e b_inverse is a number in the range 0 to M-1, which when multiplied with b, modulo M yields 1.
Note : also note that modular inverse of some numbers might not exist we can check that by taking the GCD of M and the number concerned(in our example "b") if GCD is not equal to 1 the the modular inverse does not exist.
A uses RSA encryption for her email. B finds an encrypted email to A: c = m^e mod n that he wants to know the plain text. B knows that when A replies to her email, she always includes the text of the message she is responding to in the reply.
Assume A only receives messages that are bit strings of length at most log n, which can be
mapped to Zn.
Also assume that B cannot simply send c as his own email to A and expect a reply, but that A will respond to email messages other than c.
How can B learn m using only c, e, n and random values from Zn?
From wikipedia:
RSA has the property that the product
of two ciphertexts is equal to the
encryption of the product of the
respective plaintexts. That is m1^e m2^e≡(m1m2)^e (mod n) Because
of this multiplicative property a
chosen-ciphertext attack is possible.
E.g. an attacker, who wants to know
the decryption of a ciphertext c = m^e
(mod n) may ask the holder of the
private key to decrypt an
unsuspicious-looking ciphertext c' =
cr^e (mod n) for some value r chosen by
the attacker. Because of the
multiplicative property c' is the
encryption of mr (mod n). Hence, if
the attacker is successful with the
attack, he will learn mr (mod n) from
which he can derive the message m by
multiplying mr with the modular
inverse of r modulo n.
That's actually pretty neat, thanks for asking the question that lead me to learning this.
As for your question of 3020 vs 600, it's multiplicative; rarely are concatenations used in mathematics, since after all we should always be working independent of base.
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.