DragonFly BSD
DragonFly users List (threaded) for 2005-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

So, what about "(b) RSA is just a better protocol [(algorighm)]"?


From: Adrian Bocaniciu <a.bocaniciu@xxxxxxxxxxxx>
Date: Tue, 18 Jan 2005 20:27:22 +0000

 I've read a few pieces which recommend RSA over DSA, although most 
	Re:
 RSA vs DSA
	
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kris Maglione wrote:
 > So, what about "(b) RSA is just a better protocol [(algorighm)]"?
 > I've read a few pieces which recommend RSA over DSA, although most
 > crypto programs (OpenSSL/SSH etc.) say RSA is depricated/a last resort.
 > Any insights?

    Neither DSA nor RSA are deprecated.  Both algorithms are OK to use 
for digital signatures (i.e. the signatures cannot be forged now or in 
the near future), if their parameters, i.e. the key lengths, are chosen 
correctly.

    The RSA algorithm can also be used for public-key encryption, but 
that is not recommended, because there are better ways to accomplish 
that and also because some older variants of using RSA for encryption 
are broken. (Despite that, most HTTPS Web sites are still using obsolete 
SSL libraries or configurations, which also use RSA for encryption, not 
only for authentication).

    DSA and RSA are the only digital signature algorithms that are both 
standardized and free from patents.  There was a time when RSA was not 
recommended because it was covered by a patent, but now that patent has 
expired.  There are also other digital signature algorithms that are 
better for some applications, e.g. Rabin-Williams, which can be verified 
much faster than RSA, but they are not standardized (except in IEEE 
1363, which is not widely implemented yet).  Other algorithms, like 
those using elliptic curves, are claimed to be covered by US patents, so 
they cannot be recommended while there are free alternatives.

    For RSA, a 1536-bit key pair is recommended now for most uses e.g. 
SSH public-key authentication, but longer keys shall be used for signing 
documents that should not be forged even after many years.  
Nevertheless, most Web sites that use HTTPS, have only 1024-bit RSA key 
pairs, those are still reasonably secure for now, but in a few years 
they will become breakable.  An 1536-bit RSA public/private key pair 
requires about the same time for breaking as a 90-bit key of a 
secret-key algorithm.  Nonetheless, in reality 1536-bit RSA is much more 
secure than 90-bit, because either a huge memory (much beyond what is 
currently possible) is needed for the computation or, if the memory is 
unavailable, the computation becomes much slower, so the RSA key will be 
equivalent in strength with a longer secret key.

    RSA is more appropriate for signing certificates, because it can be 
verified faster, but for the authentication of the initial message 
exchange in network connection establishments, like in IPsec, TLS/SSL or 
SSH, DSA can be better, because there are an equal number of signing and 
verification operations, so only the sum of the execution times for 
signing and verification matters.  DSA has the advantage that it has the 
same security as RSA at a shorter key length, i.e. 1280-bit DSA has 
about the same security as 1536-bit RSA.  For that reason I always use 
1280-bit DSA key pairs for SSH authentication, i.e. the keys are 
generated with "ssh-keygen -t dsa -b 1280", both for the server host key 
and for the users' workstations.

    DSA has a disadvantage that is not a property of the algorithm but 
only of its implementation in OpenSSL, OpenSSH and other common 
programs, it has several parameters that must be increased 
simultaneously for better security, but applications like ssh-keygen let 
you specify only the key length and they keep the other parameters 
unchanged.  Because of that it is absolutely useless to increase the DSA 
key length beyond 1280-bit, because the security is not improven.  On 
the other hand, with RSA you can specify 2048-bit, 3072-bit or longer 
key pairs, if you so desire.

       Best regards !




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]