welcome: please sign in

The following 248 words could not be found in the dictionary of 7 words (including 7 LocalSpellingWords) and are highlighted below:
about   absolutely   ac   accept   Adleman   advantage   after   Algorithm   algorithm   all   always   an   An   and   applications   appropriate   are   as   at   attacker   Authentication   authentication   badly   be   Because   because   become   becomes   believe   below   better   beyond   bit   bits   both   breakable   breaking   but   can   certificates   changed   chiark   choice   Choosing   common   computation   Conclusion   Conclusions   connection   context   Context   copied   currently   desire   developers   Digital   disadvantage   do   documents   don   dsa   edu   either   equal   equivalent   establishments   even   exchange   execution   exposed   extent   faq   far   faster   few   For   for   forged   From   from   generated   generator   great   greenend   hand   has   have   host   However   html   http   huge   Hull   if   If   implement   implementation   implemented   improven   in   increase   increased   indeed   informed   initial   instead   is   it   its   keep   key   keygen   keys   length   let   like   limits   log   longer   maine   major   many   matters   meaning   memory   message   more   most   much   must   my   nearly   need   needed   network   Nevertheless   Nonetheless   not   Note   now   number   numbers   of   On   on   only   Open   openssh   operations   or   org   other   pair   pairs   parameters   policy   possible   predict   private   probably   produces   programs   property   Psec   Pu   public   purposes   putty   random   reality   reason   reasonably   recommend   recommended   referenced   relies   rely   requires   Rick   Rivest   romeo   same   secret   secure   security   server   several   sgtatham   shall   Shamir   shorter   should   shown   Signature   signing   simultaneously   sites   slower   so   specify   ssh   still   strength   suffer   sum   systems   text   than   that   The   the   there   they   this   those   time   times   to   too   top   uk   umfk   unavailable   unchanged   use   used   useless   users   uses   various   verification   verified   version   was   ways   we   weakness   Web   websites   were   what   which   will   with   workstations   www   years   you  

Clear message
Edit

DSAvsRSA

1. Choosing DSA (Digital Signature Algorithm) or RSA (Rivest, Shamir, Adleman)

1.1. For the purposes of SSH Authentication

The text below was copied from various referenced websites. Conclusions are shown at the top, with context below.

From http://ac.umfk.maine.edu/~romeo/?p=69:

Conclusion:

I always use 1280-bit DSA key pairs for SSH authentication, i.e. the keys are generated withssh-keygen -t dsa -b 1280″ 

Note: my version of openssh limits DSA keys to 1024 bits. -- RickHull

Context:

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 withssh-keygen -t dsa -b 1280″, both for the server host key
and for the usersworkstations.

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. 

From PuTTY FAQ:

Conclusion:

we still recommend you use RSA instead 

Context:

DSA has a major weakness if badly implemented: it relies on a random number generator to far too great an extent. If the random number generator produces a number an attacker can predict, the DSA private key is exposed - meaning that the attacker can log in as you on all systems that accept that key.

The PuTTY policy changed because the developers were informed of ways to implement DSA which do not suffer nearly as badly from this weakness, and indeed which don't need to rely on random numbers at all. For this reason we now believe PuTTY's DSA implementation is probably OK. However, if you have the choice, we still recommend you use RSA instead. 

DSAvsRSA (last edited 2008-07-07 04:28:21 by localhost)