begin process at 2013 05 20 10:47:41
  Trouver un code source :
 
dans
 

RFC4772 :: Security Implications of Using the Data Encryption Standard (DES)

Security Implications of Using the Data Encryption Standard (DES)

Voir toute la rfc dans une seule page

Page : 5 / 28

Télécharger le PDF

Auteur(s) : S. Kelly

RFC 4772               DES Security Implications           December 2006


   these remain purely theoretical in nature at present, at least one
   was recently implemented using a FPGA that can deduce a DES key in
   12-15 hours [FPL02].  Clearly, DES cannot be considered a "strong"
   cryptographic algorithm by today's standards.

   To summarize current recommendations on using DES, the simple answer
   is "don't use it - it's not safe."  While there may be use cases for
   which the security of DES would be sufficient, it typically requires
   a security expert to determine when this is true.  Also, there are
   much more secure algorithms available today (e.g., 3DES, AES) that
   are much safer choices.  The only general case in which DES should
   still be supported is when it is strictly required for backward
   compatibility, and when the cost of upgrading outweighs the risk of
   exposure.  However, even in these cases, recommendations should
   probably be made to phase out such systems.

   If you are simply interested in the current recommendations, there
   you have it: don't use DES.  If you are interested in understanding
   how we arrive at this conclusion, read on.

2.  Why Use Encryption?

   In order to assess the security implications of using DES, it is
   useful and informative to review the basic rationale for using
   encryption.  In general, we encrypt information because we desire
   confidentiality.  That is, we want to limit access to information, to
   keep something private or secret.  In some cases, we want to share
   the information within a limited group, and in other cases, we may
   want to be the sole owner of the information in question.

   Sometimes, the information we want to protect has value only to the
   individual (e.g., a diary), and a loss of confidentiality, while
   potentially damaging in some limited ways, would typically not be
   catastrophic.  In other cases, the information might have significant
   financial implications (e.g., a company's strategic marketing plan).
   And in yet others, lives could be at stake.

   In order to gauge our confidentiality requirements in terms of
   encryption strength, we must assess the value of the information we
   are trying to protect, both to us and to a potential attacker.  There
   are various metrics we can employ for this purpose:

   o  Cost of confidentiality loss: What could we lose if an adversary
      were to discover our secret?  This gives some measure of how much
      effort we should be willing to expend to protect the secret.






Kelly                        Informational                      [Page 5]



Nos sponsors


Sondage...

Comparez les prix

CalendriCode

Mai 2013
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Photothèque

A découvrir



 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,250 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales