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.
Related
I have edited the question after the clarification of Marcus in his commment.
I have a question and I am unable to find the answer using Google.
I know that in S/MIME encryption or with GnuPG/Enigmail, the plain text is first encrypted with a symmetric algorithm such as AES or 3DES or IDEA, and the password used for the symmetric encryption is encrypted with an asymmetric algorithm (RSA).
MY question, is possible using gpg or openssl to knows the symmetric algorithm used and do a partial encryption, in other words I would to decrypt only the asymmetric algorithm to view the password used for the symmetric encryption.
I'll try to explain it using math notation :
T -> plain text
s -> the symmetric algorithm encryption
p -> the password used by symmetric encryption function
a -> the asymmetric encryption function (RSA), it merges cyphered text and other data too.
k -> my public key
When someone send me a message I receive C and, since I have my private key, I decrypt it using it
C = a(p, k) + s(T, p)
I would to know s(T, p) and p, if possible.
I've learned the theory of public key encryption but I'm missing the connection to the physical world. e.g.
I've been told that good RSA encryption should rely on prime numbers with 300 decimal digits but why? who came up with this number? How long it will take to break such encryption (statistics about different machines).
I've tried Google, but couldn't find what I wanted. anyone?
thanks
The key of asymmetric cryptography is to have an asymmetric function which allow decrypting message encrypted by the asymmetric key, without allowing to find the other key. In RSA, the function used is based on factorization of prime numbers however it is not the only option (Elliptic curve is another one for example).
So, basically you need two prime numbers for generating a RSA key pair. If you are able to factorize the public key and find these prime numbers, you will then be able to find the private key. The whole security of RSA is based on the fact that it is not easy to factorize large composite numbers, that's why the length of the key highly change the robustness of the RSA algorithm.
There are competitions to factorize large prime numbers with calculators each years with nice price. The last step of factorizing RSA key was done in 2009 by factorizing 768 bits keys. That's why at least 2048 bit keys should be used now.
As usual, Wikipedia is a good reference on RSA.
All public key algorithms are based on trapdoor functions, that is, mathematical constructs that are "easy" to compute in one way, but "hard" to reverse unless you have also some additional information (used as private key) at which point also the reverse becomes "easy".
"Easy" and "hard" are just qualitative adjectives that are always more formally defined in terms of computational complexity. "Hard" very often refers to computations that cannot be solved in polynomial time O(nx) for some fixed x and where n is the input data.
In the case of RSA, the "easy" function is the modular exponentiation C = Me mod N where the factors of N are kept secret. The "hard" problem is to find the e-th root of C (that is, M). Of course, "hard" does not mean that it is always hard, but (intuitively) that increasing the size of N by a certain factor increases the complexity by a much larger factor.
The sizes of the modulus which are recommended (2048 bits, or 617 decimal digits) relate to the availability of computation power at present time, so that if you stick to them you are assured that it will be extremely expensive for the attacker to break it. For more details, I should refer you to a brilliant answer on cryptography.SE (go and upvote :-)).
Finally, in order to have a trapdoor, N is built so as to be a composite number. It theory, for improved performance, N may have more than 2 factors, but the general security rule is that all factors must be balanced and have roughly the same size. That means that if you have K factors, and N is B bits long, each factor is roughly B/K bits longs.
This problem to solve is not the same as the integer factorization problem though. The two are related in that if you manage to factor N you can compute the private key by re-doing what the party that generated the key did. Typically, the exponent e being used is very small (3); it cannot be excluded that someday somebody devises an algorithm to compute the e-th without factoring N.
EDIT: Corrected the number of decimal digits for the modulus of a 2048 bits RSA key.
RSA uses the idea of one-way math functions, so that it's easy to encrypt and decrypt if you have the key, but hard (as in it takes lots and lots of CPU cycles) to decrypt if you don't have the key. Even before they thought of using prime numbers, mathematicians identified the need for a one-way function.
The first method they hit upon was the idea that if your "key" is a prime number, and your message is another number, then you can encrypt by multiplying the two together. Someone with the key can easily divide out the prime number and get the message, but for someone without the prime number, figuring out the prime number key is hard.
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.
Is possible to calculate average of three encrypted integer? No constrain on the method of encrypting. The point of this is just to hide the three numbers and find average.
What you seem to be looking for is called Homomorphic Encryption: an encryption scheme which allows you to perform operations on encrypted data, with the encrypted result as the outcome.
Such a scheme would allow you to give encrypted data to a 3rd party, which could then do computations on it for you without knowing what they were computing.
In your case, you need two operations: addition and division. Until recently, homomorphic encryption schemes typically supported only 1 operation. But in september 2009 IMB announced the first fully homomorphic cryptosystem. Other researches published another system soon after that.
These cryptosystems might be be able to do what you want, but it is all cutting edge computer science research.
Decrypt the numbers, then calculate their average.
I don't see any simple ways to do what you ask, apart from decrypting the numbers first.
Taking the average (or the "arithmetic mean") requires adding the numbers. Now if you wanted to multiply the numbers, then you could do that neatly with RSA encryption. If p is the plaintext, c is the ciphertext, and e is the encryption key, then in RSA, c = p^e. If you have 3 separate integers, p1, p2, p3, and the product is pp then
pp^e = (p1 * p2 * p3)^e = p1^e * p2^e * p3^3 = c1 * c2 * c3 = cp
That is, you can either multiply the three plaintext integers together and then encrypt, or you can just multiply the three ciphertexts together, and get the same answer. This would get you some way towards the "geometric mean", where you multiply all the numbers together, and then take the cube-root (or nth root for n numbers). Unfortunately, calculating a cube root in modular arithmetic is non-trivial.
With ideal encryption methods: No.
With most real-world encryption methods: No.
With some stupidly simple to undo obfuscation method especially designed to allow averaging: Yes.
Calling the latter method "encryption" really would be using the wrong term.
If you could calculate the average of encrypted numbers without decrypting them, that would make decrypting the original numbers quite a lot easier, so I would be very surprised if this works with any serious encryption algorithm.
In general three encrypted numbers shouldn't maintain the same order if encrypted, so I'm pretty sure you have to decrypt them and calculate the avarage.
If, and only if, the method of encryption is a one-to-one mathematical function, then it is possible to do so while the numbers are encrypted.
For example, if my very unsecure method of encryption is to multiply every number of 2, then I would do the following:
function encrypt($number){
return $number*2;
}
$a=encrypt(3); // a= 9
$b=encrypt(5); // b= 15
$c=encrypt(6); // c= 18
$average = ($a+$b+$c)/6; // We divide by 6 because first we divide by 3 to get the average, then by 2 to do the decryption. The method will vary based on the mathematical function.
The only other possibility is to decrypt the numbers first.
What is DES-X?
And
DES-X and DES, are they backwards compatible?
Well, DES-X is a variant of the DES block cipher (as I'm sure you already knew).
The reason for the introduction of the DES-X was an attempt to increase the security of the original DES algorithm (which was limited to a 56bit key). The proposed solution with DEX-X was to use two more 64-bit keys which would be applied to make it harder for an attacker to guess the key of the DES algorithm. Basically, the first additional key is XORed to the plain text which is then encrypted with DES. The second additional key is XORed to the resulting cypher.
However, as far the backwards compatibility.. I'm not sure what you mean by that? If you're asking if you can use DES to decrypt DES-X messages then NO (it the strict sense). If you're asking whether a DES-X implementation could be configured to encrypt/decrypt DES messages then the answer is YES.
Here's an example:
DES(msg) = CYPHER
DES-X(msg) = K2 X DES(K1 x msg) = CYPER-X
If you choose K2 and K1 to be the all 0 then:
DES-x(msg) = K2 x DES(K1 x msg) [where K1 = 0, K2 =0] = DES(msg)
It should be pointed out that what I mean by making K1 and K2 0 is actually choosing a key which is 64 bits of 0 = {0,0,0,0,0...0} (64 times). Such a key does not modify the plaintext of the cypher at all when the XOR operation is applied.
DES and DES-X are both block ciphers.
See http://en.wikipedia.org/wiki/DES-X
for more details. In short, DES-X adds key whitening.
Here's the wikipedia article on DES-X. DES-X increases the key size by appending XOR'd versions of the key before and after the encryption.
The summary of this paper says that DES-X is "compatible." However, I'm not sure if that includes backwards-compatibility.
http://www.cs.ucdavis.edu/~rogaway/papers/cryptobytes.ps