Guide to Cryptography - Revision history

Peter Mosmans: Remove the use of 3DES and correct the keysize

2018-06-13T09:59:11Z

Remove the use of 3DES and correct the keysize

Sarciszewski: /* How to protect yourself */

2015-09-12T16:15:05Z

‎How to protect yourself

Shady at 02:22, 26 February 2012

2012-02-26T02:22:24Z

KirstenS: /* How to determine if you are vulnerable */

2009-05-03T16:01:14Z

‎How to determine if you are vulnerable

KirstenS: /* Asymmetric Cryptography (also called Public/Private Key Cryptography) */

2009-05-03T15:59:33Z

‎Asymmetric Cryptography (also called Public/Private Key Cryptography)

KirstenS: /* Cryptography */

2009-03-04T15:04:34Z

‎Cryptography

KirstenS: /* Further Reading */

2009-03-04T15:03:53Z

‎Further Reading

KirstenS: /* Further Reading */

2009-03-04T15:03:08Z

‎Further Reading

KirstenS: /* Further Reading */

2009-03-04T15:02:34Z

‎Further Reading

KirstenS: /* Summary */

2009-03-04T15:01:34Z

‎Summary

@@ Line 1: / Line 1: @@
-[[Guide Table of Contents|Development Guide Table of Contents]]__TOC__
+[[Guide Table of Contents|Development Guide Table of Contents]]
 ==Objective ==
@@ Line 57: / Line 59: @@
 Symmetric Cryptography is the most traditional form of cryptography.  In a symmetric cryptosystem, the involved parties share a common secret (password, pass phrase, or key). Data is encrypted and decrypted using the same key. These algorithms tend to be comparatively fast, but they cannot be used unless the involved parties have already exchanged keys.  Any party possessing a specific key can create encrypted messages using that key as well as decrypt any messages encrypted with the key.  In systems involving a number of users who each need to set up independent, secure communication channels symmetric cryptosystems can have practical limitations due to the requirement to securely distribute and manage large numbers of keys.
-Common examples of symmetric algorithms are DES, 3DES and AES. The 56-bit keys used in DES are short enough to be easily brute-forced by modern hardware and DES should no longer be used.  Triple DES (or 3DES) uses the same  algorithm, applied three times with different keys giving it an effective key length of 128 bits.  Due to the problems using the DES alrgorithm, the United States National Institute of Standards and Technology (NIST) hosted a selection process for a new algorithm.  The winning algorithm was Rijndael and the associated cryptosystem is now known as the Advanced Encryption Standard or AES.  For most applications 3DES is acceptably secure at the current time, but for most new applications it is advisable to use AES.
+Common examples of symmetric algorithms are DES, 3DES and AES. The 56-bit keys used in DES are short enough to be easily brute-forced by modern hardware and DES should no longer be used. Triple DES (or 3DES) uses the same  algorithm, applied three times with different keys giving it an effective key length of 112 bits (due to an attack that reduces the strength to the work that would be involved).  Due to the problems using the DES algorithm, the United States National Institute of Standards and Technology (NIST) hosted a selection process for a new algorithm.  The winning algorithm was Rijndael and the associated cryptosystem is now known as the Advanced Encryption Standard or AES. It is advisable to use AES, as DES is deprecated.
 ===Asymmetric Cryptography (also called Public/Private Key Cryptography) ===
@@ Line 69: / Line 71: @@
 Another usage scenario is one where User A wants to send User B a message and wants User B to have a guarantee that the message was sent by User A.  In order to accomplish this, User A would encrypt the message with their Private Key.  The message can then only be decrypted using User A’s Public Key.  This guarantees that User A created the message Because they are then only entity who had access to the Private Key required to create a message that can be decrcrypted by User A’s Public Key.  This is essentially a digital signature guaranteeing that the message was created by User A.
-A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their ‘root’ certificates, which in turn authenticate the public certificate presented by the server.[[Category:FIXME|seems like there should be a noun after "avialable"]]
+A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their ‘root’ certificates, which in turn authenticate the public certificate presented by the server.
 PGP and SSL are prime examples of a systems implementing asymmetric cryptography, using RSA or other algorithms.
@@ Line 290: / Line 293: @@
 <u>http://seclists.org/bugtraq/1999/Dec/208</u>
-* Schneier, B. ''Is 1024 bits enough?, ''April 2002 Cryptogram''
+* Schneier, B. ''Is 1024 bits enough?, ''April 2002 Cryptogram
-''<u>http://www.schneier.com/crypto-gram-0204.html#3</u>
+''<u>http://www.schneier.com/crypto-gram-0204.html#3</u> ''
 * Schneier, B., Cryptogram,
@@ Line 346: / Line 349: @@
-The following values are the allowed algorithm parameters''' ''':
+The following values are the allowed algorithm parameters:
@@ Line 412: / Line 415: @@
-ColdFusion offers the following default algorithms for these functions''' ''':
+ColdFusion offers the following default algorithms for these functions:
 CFMX_COMPAT: the algorithm used in ColdFusion MX and prior releases. This algorithm is the least secure option (default).
@@ Line 430: / Line 433: @@
-The following algorithms are provided by default for the hash() function. Note, SHA algorithms used in ColdFusion are NIST FIPS-180-2 compliant''' ''':
+The following algorithms are provided by default for the hash() function. Note, SHA algorithms used in ColdFusion are NIST FIPS-180-2 compliant:
 CFMX_COMPAT: Generates a MD5 hash string identical to that generated by ColdFusion MX and ColdFusion MX 6.1 (default).
@@ Line 448: / Line 451: @@
 '''Pluggable Encryption'''
-ColdFusion MX 7 introduced pluggable encryption for CFML. The JCE allows developers to specify multiple cryptographic service providers. ColdFusion can leverage the algorithms, feedback modes, and padding methods of third-party Java security providers to strengthen its cryptography functions. For example, ColdFusion can leverage the Bouncy Castle ('''<u>http://www.bouncycastle.org/'''</u>) crypto package and use the SHA-224 algorithm for the hash() function or the Serpent block encryption for the encrypt() function.
+ColdFusion MX 7 introduced pluggable encryption for CFML. The JCE allows developers to specify multiple cryptographic service providers. ColdFusion can leverage the algorithms, feedback modes, and padding methods of third-party Java security providers to strengthen its cryptography functions. For example, ColdFusion can leverage the Bouncy Castle ('''<u>http://www.bouncycastle.org/''') crypto package and use the SHA-224 algorithm for the hash() function or the Serpent block encryption for the encrypt() function.

← Older revision		Revision as of 16:15, 12 September 2015
Line 116:		Line 116:

	* Consider 168 or 256 bits for secure systems such as large financial transactions		* Consider 168 or 256 bits for secure systems such as large financial transactions
		+
		+	* [https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly Symmetric-key encryption protocols should include message authentication]
		+
		+	* [http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ Always Encrypt then MAC!]

	'''Asymmetric:'''		'''Asymmetric:'''

@@ Line 284: / Line 284: @@
 * Bindview, ''Vulnerability in Windows NT's SYSKEY encryption''
-<u>http://www.bindview.com/Services/razor/Advisories/1999/adv_WinNT_syskey.cfm</u> [[category:FIXME|is this going to the correct page?]]
+<u>http://seclists.org/bugtraq/1999/Dec/208</u>
 * Schneier, B. ''Is 1024 bits enough?, ''April 2002 Cryptogram''
@@ Line 292: / Line 292: @@
 * Schneier, B., Cryptogram,
-<u>http://www.counterpane.com/cryptogram.html</u> [[category:FIXME|link not working]]
+<u>http://www.schneier.com/crypto-gram.html</u>
 * NIST, Replacing SHA-1 with stronger variants: SHA-256 ? 512
-<u>http://csrc.nist.gov/CryptoToolkit/tkhash.html</u> [[category:FIXME|these two links go to the same page]]
+<u>http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html</u>
 * UUIDs are only unique if you generate them:

@@ Line 105: / Line 105: @@
 Cryptography is a constantly changing field. As new discoveries in cryptanalysis are made, older algorithms will be found unsafe. In addition, as computing power increases the feasibility of brute force attacks will render other cryptosystems or the use of certain key lengths unsafe. Standard bodies such as NIST should be monitored for future recommendations.
-Specific applications, such as banking transaction systems may have specific requirements for algorithms and key sizes.
+Specific applications, such as banking transaction systems, may have specific requirements for algorithms and key sizes.
 ===How to protect yourself ===

@@ Line 69: / Line 69: @@
 Another usage scenario is one where User A wants to send User B a message and wants User B to have a guarantee that the message was sent by User A.  In order to accomplish this, User A would encrypt the message with their Private Key.  The message can then only be decrypted using User A’s Public Key.  This guarantees that User A created the message Because they are then only entity who had access to the Private Key required to create a message that can be decrcrypted by User A’s Public Key.  This is essentially a digital signature guaranteeing that the message was created by User A.
-A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their ‘root’ certificates, which in turn authenticate the public certificate presented by the server.
+A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their ‘root’ certificates, which in turn authenticate the public certificate presented by the server.[[Category:FIXME|seems like there should be a noun after "avialable"]]
 PGP and SSL are prime examples of a systems implementing asymmetric cryptography, using RSA or other algorithms.

← Older revision		Revision as of 15:04, 4 March 2009
Line 310:		Line 310:
	==Cryptography ==		==Cryptography ==

−	The following section describes ~~the~~ ColdFusion’s cryptography features. ColdFusion MX leverages the Java Cryptography Extension (JCE) of the underlying J2EE platform for cryptography and random number generation. It provides functions for symmetric (or private-key) encryption. While it does not provide native functionality for public-key (asymmetric) encryption, it does use the Java Secure Socket Extension (JSSE) for SSL communication.	+	The following section describes ColdFusion’s cryptography features. ColdFusion MX leverages the Java Cryptography Extension (JCE) of the underlying J2EE platform for cryptography and random number generation. It provides functions for symmetric (or private-key) encryption. While it does not provide native functionality for public-key (asymmetric) encryption, it does use the Java Secure Socket Extension (JSSE) for SSL communication.

@@ Line 272: / Line 272: @@
 A web application can implement cryptography at multiple layers: application, application server or runtime (such as .NET), operating system and hardware. Selecting an optimal approach requires a good understanding of application requirements, the areas of risk, and the level of security strength it might require, flexibility, cost, etc.
-Although cryptography is not a panacea, the majority of security breaches do not come from brute force computation but from exploiting mistakes in implementation. The strength of a cryptographic system is measured in key length. Using a large key length and then storing the unprotected keys on the same server, eliminates most of the protection benefit gained. Besides the secure storage of keys, another classic mistake is engineering custom cryptographic algorithms (to generate random session ids for example). Many web applications were successfully attacked because the developers thought they could create their crypto functions.
+Although cryptography is not a panacea, the majority of security breaches do not come from brute force computation but from exploiting mistakes in implementation. The strength of a cryptographic system is measured in key length. Using a large key length and then storing the unprotected keys on the same server eliminates most of the protection benefit gained. Besides the secure storage of keys, another classic mistake is engineering custom cryptographic algorithms (to generate random session ids for example). Many web applications were successfully attacked because the developers thought they could create their crypto functions.
 Our recommendation is to use proven products, tools, or packages rather than rolling your own.