---
created_at: '2014-03-20T22:38:02.000Z'
title: Cryptographic Right Answers (2009)
url: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html
author: bshanks
points: 52
story_text: ''
comment_text: 
num_comments: 40
story_id: 
story_title: 
story_url: 
parent_id: 
created_at_i: 1395355082
_tags:
- story
- author_bshanks
- story_7439363
objectID: '7439363'

---
[Source](http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html "Permalink to Cryptographic Right Answers")

# Cryptographic Right Answers

# [Daemonic Dispatches][1]

Musings from Colin Percival 

## Cryptographic Right Answers

Thanks to my background as FreeBSD Security Officer, as a cryptographic researcher, and as the author of the [Tarsnap][2] secure online backup system, I am frequently asked for advice on using cryptography as a component in secure systems. While some people [argue that you should never use cryptographic primitives directly][3] and that trying to teach people cryptography just makes them more likely to shoot themselves in their proverbial feet, I come from a proud academic background and am sufficiently optimistic about humankind that I think it's a good idea to spread some knowledge around. In light of this, I've put together a list of "Cryptographically Right Answers" -- which is to say, a list of recommendations for using cryptography which, if followed, will make sure you get things right in the vast majority of situations. 

**Encrypting data: Use [AES][4] in [CTR][5] (Counter) mode, and append an [HMAC][6].**   
AES is about as standard as you can get, and has done a good job of resisting cryptologic attacks over the past decade. Using CTR mode avoids the weakness of ECB mode, the complex (and bug-prone) process of padding and unpadding of partial blocks (or ciphertext stealing), and vastly reduces the risk of side channel attacks thanks to the fact that the data being input to AES is not sensitive. However, because CTR mode is malleable, you should always add an HMAC to confirm that the encrypted data has not been tampered with.   
In some situations it may be preferable for performance reasons to use a cipher mode such as GCM which combines encryption and authentication; but this benefit is small (HMACs are fast) and increases the risk of side channel attacks (because attacker-supplied input is processed).   
**UPDATE:** I've posted a more detailed explanation about [why I recommend using the Encrypt-then-MAC composition][7]. 

**AES key length: Use 256-bit AES keys.**   
Theoretically speaking, 128-bit AES keys should be enough for the forseeable future; but for most applications the increased cost of using 256-bit keys instead of 128-bit keys is insignificant, and the increased key length provides a margin of security in case a side channel attack leaks some but not all of the key bits. 

**Symmetric signatures (added 2009-09-28): Use an [HMAC][6].**   
I didn't think it was necessary to point this out, but I realize now (2009-09-28, three months after first writing this list) that there are some people for whom it should be spelled out. Do not design your own way of generating symmetric signatures (e.g., for API requests); especially avoid the common "concatenate key and data, then input to a hash function" approach. 

**Hash / HMAC algorithm: Use [SHA256][8] / HMAC-SHA256 for now, but plan on upgrading to [the upcoming SHA-3][9] hash within the next 5-10 years.**   
Given the recent attacks on MD5 and SHA1, I would not be surprised if SHA256 is "broken" within the next few years; but moving from a theoretical break (i.e., an algorithm for finding a collision in less than 2^128 time) to a practical weakness is likely to take several years (based on the history of past hash algorithms). While SHA512 could be used as a "stop-gap" measure in the event the SHA256 is broken before SHA-3 is available (realizing, of course, that the similarities between the designs of SHA256 and SHA512 make it likely that any weakness in SHA256 would translate to a corresponding weakness in SHA512), the fact that SHA512 uses 64-bit arithmetic makes it more likely that implementations on 32-bit systems will be vulnerable to side channel attacks. 

**Random IDs: Use 256-bit random numbers.**   
The "birthday paradox" states that in order to avoid collisions you need to select random values from twice the bit-size of the number of values you will be selecting. I doubt any application thus far has come close to selecting 2^64 random values; but if computers continue to scale exponentially, this could occur in the upcoming decade. In most applications, using 256-bit random values instead of 128-bit random values carries no significant increase in cost; but it puts randomly finding a collision safely into the realm of "not going to happen with all the computers on Earth in the lifetime of the solar system" problems. 

**Password handling: As soon as you receive a password, hash it using [scrypt][10] or [PBKDF2][11] and erase the plaintext password from memory.**   
Do NOT store users' passwords. Do NOT hash them with MD5. Use a real key derivation algorithm. PBKDF2 is the most official standard; but scrypt is stronger.   
Please keep in mind that even if YOUR application isn't particularly sensitive, your users are probably re-using passwords which they have used on other, more sensitive, websites -- so if you screw up how you store your users' passwords, you might end up doing them a lot of harm. 

**Asymmetric encryption: Use [RSAES-OAEP][12] with SHA256 as the hash function, MGF1+SHA256 as the mask generation function, and a public exponent of 65537. Make sure that you follow the decryption algorithm to the letter in order to avoid side channel attacks.**   
Many applications use PKCS #1 v1.5 encryption; this algorithm has known weaknesses and should be avoided (there are workarounds for said weaknesses -- but there might also be other undiscovered weaknesses). In contrast, RSAES-OAEP has been proven to be secure under fairly reasonable assumptions.   
I recommend using SHA256 here mostly for consistency. Many people use SHA1, and in this context it is perfectly adequate -- but why use two different hashes if you can get away with only using one?   
Using a public exponent of 65537 is not absolutely necessary -- a public exponent of 3 is theoretically just as secure -- but there have been a couple of attacks (against PKCS #1 v1.5 padding, and my cache based side channel attack) which were much easier given a small public exponent, so it's possible that using a public exponent of 65537 will help defend against weaknesses discovered in the future.   
If you are not careful about how you decrypt RSAES-OAEP-encrypted data, you will leak information which can be used to steal your key; if you follow the algorithm precisely you will be safe, but it is very easy to get this wrong. 

**Asymmetric signatures: Use [RSASSA-PSS][12] with SHA256 as the hash function, MGF1+SHA256 as the mask generation function, and a public exponent of 65537.**   
The RSASSA-PSS signature scheme has been proven to be secure under reasonable assumptions; there is really no reason to use anything else. Unlike RSAES-OAEP, the choice of hash function is important here; I recommend SHA256, but (as discussed above) switching to SHA-3 will be advisable once that standard is released. As with RSAES-OAEP, using a public exponent of 65537 is not strictly necessary, but might help prevent some attacks.   
Many people recommend using DSA or elliptic curve based signature schemes which are faster and/or produce smaller signatures than RSASSA-PSS; in some situations these advantages are important, but in most cases I prefer RSASSA-PSS because its relative simplicity makes implementation errors and side channel attacks less likely. 

**Diffie-Hellman: Operate over the 2048-bit [Group #14][13] with a generator of 2. Be careful about side channel attacks.**   
This group is large enough that it should be secure for the near future; and as it is defined based on the binary digits of Pi, it clearly was not chosen to have any specific weaknesses. There is absolutely no excuse for allowing Diffie-Hellman groups to be defined at run-time; this adds a great deal of complexity and potential for cryptographic weaknesses, and serves no purpose whatesoever.   
Because Diffie-Hellman requires operating on attacker-supplied input, there is a significant danger of side channel attacks; using some form of base or exponent blinding may be required. 

**Website security: Use OpenSSL.**   
OpenSSL has a [horrible track record][14] for security; but it has the saving grace that because it is so widely used, vendors tend to be very good at making sure that OpenSSL vulnerabilities get fixed promptly. I wish there was a better alternative, but for now at least OpenSSL is the best option available.   
**UPDATE:** For added security, [terminate SSL connections in restricted environment][15] and pass the raw HTTP over a loopback connection to your web server. 

**Client-server application security: Distribute the server's public RSA key with the client code, and do not use SSL.**   
One of the reasons OpenSSL has such a poor track record is that the SSL protocol itself is highly complex. Certificate chains, revocation lists, ASN.1, multiple different hashing and encryption schemes... when you have over a hundred thousand lines of code, it's no wonder that bugs creep in.   
If you're distributing client code which speaks to a server you operate, there is no need to use SSL; instead, you can distribute the server's public RSA key (or its hash) along with the client code, and "bootstrap" the security process that way. I do this in FreeBSD for the FreeBSD Update and Portsnap services, and I also do this in Tarsnap. It's simple; it works; and it's secure. 

**Online backups: Use [Tarsnap][2].**   
Ok, I have a slight bias here! -- but in all honesty, I do trust Tarsnap's security far more than that of any other backup system, and not just because I wrote tarsnap. Most backup systems are written by people who are interested in backups, and have security more or less as an afterthought; in contrast, I know very little about backups (I would never have gotten started with tarsnap if it hadn't been for Tim Kientzle writing his excellent [libarchive][16] library and effectively dropping a free tar implementation in my lap), but I do know a lot about cryptography and security; and I wrote tarsnap from that perspective. 

While I agree that most of my readers should never write any cryptographic code, I hope that those of you who do end up writing cryptographic code will end up writing better and more secure code thanks to this -- and more importantly, I hope those of you who never write any cryptographic code will learn enough from this that you will be able to recognize when people are doing things wrong. Bugs become shallow given enough eyeballs -- but only when those eyeballs know enough about the relevant code to be able to recognize bugs when they are spotted. 

Posted at 2009-06-11 14:20 | [Permanent link][17] | [Comments][18]

[View the forum thread.][19] [blog comments powered by Disqus][20]

##  Recent posts 

[FreeBSD/EC2 history][21]

[Some thoughts on Spectre and Meltdown][22]

[FreeBSD/EC2 on C5 instances][23]

[FreeBSD/EC2: Community vs. Marketplace AMIs][24]

[Oil changes, safety recalls, and software patches][25]

[A plan for open source software maintainers][26]

[Cheating on a string theory exam][27]

[IPv6 on FreeBSD/EC2][28]

[A very valuable vulnerability][29]

[EC2's most dangerous feature][30]

##  Monthly Archives 

[February 2018][31]

[January 2018][32]

[November 2017][33]

[October 2017][34]

[June 2017][35]

[May 2017][36]

[February 2017][37]

[January 2017][38]

[October 2016][39]

[April 2016][40]

[January 2016][41]

[December 2015][42]

[November 2015][43]

[September 2015][44]

[August 2015][45]

[April 2015][46]

[January 2015][47]

[December 2014][48]

[November 2014][49]

[October 2014][50]

[September 2014][51]

[April 2014][52]

[March 2014][53]

[February 2014][54]

[January 2014][55]

[December 2013][56]

[November 2013][57]

[September 2013][58]

[August 2013][59]

[June 2013][60]

[January 2013][61]

[December 2012][62]

[November 2012][63]

[October 2012][64]

[September 2012][65]

[August 2012][66]

[July 2012][67]

[May 2012][68]

[March 2012][69]

[January 2012][70]

[December 2011][71]

[September 2011][72]

[August 2011][73]

[July 2011][74]

[June 2011][75]

[May 2011][76]

[April 2011][77]

[March 2011][78]

[February 2011][79]

[January 2011][80]

[December 2010][81]

[October 2010][82]

[September 2010][83]

[August 2010][84]

[July 2010][85]

[June 2010][86]

[April 2010][87]

[March 2010][88]

[December 2009][89]

[October 2009][90]

[September 2009][91]

[August 2009][92]

[July 2009][93]

[June 2009][94]

[May 2009][95]

[April 2009][96]

[March 2009][97]

[February 2009][98]

[January 2009][99]

[December 2008][100]

[November 2008][101]

[October 2008][102]

[September 2008][103]

[June 2008][104]

[May 2008][105]

[April 2008][106]

[March 2008][107]

[February 2008][108]

[January 2008][109]

[December 2007][110]

[November 2007][111]

[October 2007][112]

[September 2007][113]

[August 2007][114]

[June 2007][115]

[May 2007][116]

[March 2007][117]

[February 2007][118]

[January 2007][119]

[November 2006][120]

[October 2006][121]

[September 2006][122]

[August 2006][123]

[July 2006][124]

[June 2006][125]

[May 2006][126]

[April 2006][127]

[March 2006][128]

[January 2006][129]

[December 2005][130]

[November 2005][131]

[October 2005][132]

[September 2005][133]

##  Yearly Archives 

[2018][134]

[2017][135]

[2016][136]

[2015][137]

[2014][138]

[2013][139]

[2012][140]

[2011][141]

[2010][142]

[2009][143]

[2008][144]

[2007][145]

[2006][146]

[2005][147]

  
[RSS][148]

[1]: http://www.daemonology.net/blog/
[2]: http://www.tarsnap.com/
[3]: http://www.matasano.com/log/1749/typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/
[4]: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[5]: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
[6]: http://en.wikipedia.org/wiki/HMAC
[7]: http://www.daemonology.net/2009-06-24-encrypt-then-mac.html
[8]: http://en.wikipedia.org/wiki/SHA256
[9]: http://en.wikipedia.org/wiki/NIST_hash_function_competition
[10]: http://www.tarsnap.com/scrypt/
[11]: http://en.wikipedia.org/wiki/PBKDF2
[12]: http://www.ietf.org/rfc/rfc3447.txt
[13]: http://www.ietf.org/rfc/rfc3526.txt
[14]: http://openssl.org/news/vulnerabilities.html
[15]: http://www.daemonology.net/2009-09-28-securing-https.html
[16]: http://code.google.com/p/libarchive/
[17]: http://www.daemonology.net/2009-06-11-cryptographic-right-answers.html
[18]: http://www.daemonology.net/2009-06-11-cryptographic-right-answers.html#disqus_thread
[19]: http://daemonicdispatches.disqus.com/?url=ref
[20]: http://disqus.com
[21]: http://www.daemonology.net/2018-02-12-FreeBSD-EC2-history.html
[22]: http://www.daemonology.net/2018-01-17-some-thoughts-on-spectre-and-meltdown.html
[23]: http://www.daemonology.net/2017-11-17-FreeBSD-EC2-C5-instances.html
[24]: http://www.daemonology.net/2017-10-21-FreeBSD-EC2-community-vs-marketplace-AMIs.html
[25]: http://www.daemonology.net/2017-06-14-oil-changes-safety-recalls-software-patches.html
[26]: http://www.daemonology.net/2017-05-11-plan-for-foss-maintainers.html
[27]: http://www.daemonology.net/2017-02-21-cheating-on-a-string-theory-exam.html
[28]: http://www.daemonology.net/2017-01-26-IPv6-on-FreeBSD-EC2.html
[29]: http://www.daemonology.net/2016-10-28-A-very-valuable-vulnerability.html
[30]: http://www.daemonology.net/2016-10-09-EC2s-most-dangerous-feature.html
[31]: http://www.daemonology.net/2018-02.html
[32]: http://www.daemonology.net/2018-01.html
[33]: http://www.daemonology.net/2017-11.html
[34]: http://www.daemonology.net/2017-10.html
[35]: http://www.daemonology.net/2017-06.html
[36]: http://www.daemonology.net/2017-05.html
[37]: http://www.daemonology.net/2017-02.html
[38]: http://www.daemonology.net/2017-01.html
[39]: http://www.daemonology.net/2016-10.html
[40]: http://www.daemonology.net/2016-04.html
[41]: http://www.daemonology.net/2016-01.html
[42]: http://www.daemonology.net/2015-12.html
[43]: http://www.daemonology.net/2015-11.html
[44]: http://www.daemonology.net/2015-09.html
[45]: http://www.daemonology.net/2015-08.html
[46]: http://www.daemonology.net/2015-04.html
[47]: http://www.daemonology.net/2015-01.html
[48]: http://www.daemonology.net/2014-12.html
[49]: http://www.daemonology.net/2014-11.html
[50]: http://www.daemonology.net/2014-10.html
[51]: http://www.daemonology.net/2014-09.html
[52]: http://www.daemonology.net/2014-04.html
[53]: http://www.daemonology.net/2014-03.html
[54]: http://www.daemonology.net/2014-02.html
[55]: http://www.daemonology.net/2014-01.html
[56]: http://www.daemonology.net/2013-12.html
[57]: http://www.daemonology.net/2013-11.html
[58]: http://www.daemonology.net/2013-09.html
[59]: http://www.daemonology.net/2013-08.html
[60]: http://www.daemonology.net/2013-06.html
[61]: http://www.daemonology.net/2013-01.html
[62]: http://www.daemonology.net/2012-12.html
[63]: http://www.daemonology.net/2012-11.html
[64]: http://www.daemonology.net/2012-10.html
[65]: http://www.daemonology.net/2012-09.html
[66]: http://www.daemonology.net/2012-08.html
[67]: http://www.daemonology.net/2012-07.html
[68]: http://www.daemonology.net/2012-05.html
[69]: http://www.daemonology.net/2012-03.html
[70]: http://www.daemonology.net/2012-01.html
[71]: http://www.daemonology.net/2011-12.html
[72]: http://www.daemonology.net/2011-09.html
[73]: http://www.daemonology.net/2011-08.html
[74]: http://www.daemonology.net/2011-07.html
[75]: http://www.daemonology.net/2011-06.html
[76]: http://www.daemonology.net/2011-05.html
[77]: http://www.daemonology.net/2011-04.html
[78]: http://www.daemonology.net/2011-03.html
[79]: http://www.daemonology.net/2011-02.html
[80]: http://www.daemonology.net/2011-01.html
[81]: http://www.daemonology.net/2010-12.html
[82]: http://www.daemonology.net/2010-10.html
[83]: http://www.daemonology.net/2010-09.html
[84]: http://www.daemonology.net/2010-08.html
[85]: http://www.daemonology.net/2010-07.html
[86]: http://www.daemonology.net/2010-06.html
[87]: http://www.daemonology.net/2010-04.html
[88]: http://www.daemonology.net/2010-03.html
[89]: http://www.daemonology.net/2009-12.html
[90]: http://www.daemonology.net/2009-10.html
[91]: http://www.daemonology.net/2009-09.html
[92]: http://www.daemonology.net/2009-08.html
[93]: http://www.daemonology.net/2009-07.html
[94]: http://www.daemonology.net/2009-06.html
[95]: http://www.daemonology.net/2009-05.html
[96]: http://www.daemonology.net/2009-04.html
[97]: http://www.daemonology.net/2009-03.html
[98]: http://www.daemonology.net/2009-02.html
[99]: http://www.daemonology.net/2009-01.html
[100]: http://www.daemonology.net/2008-12.html
[101]: http://www.daemonology.net/2008-11.html
[102]: http://www.daemonology.net/2008-10.html
[103]: http://www.daemonology.net/2008-09.html
[104]: http://www.daemonology.net/2008-06.html
[105]: http://www.daemonology.net/2008-05.html
[106]: http://www.daemonology.net/2008-04.html
[107]: http://www.daemonology.net/2008-03.html
[108]: http://www.daemonology.net/2008-02.html
[109]: http://www.daemonology.net/2008-01.html
[110]: http://www.daemonology.net/2007-12.html
[111]: http://www.daemonology.net/2007-11.html
[112]: http://www.daemonology.net/2007-10.html
[113]: http://www.daemonology.net/2007-09.html
[114]: http://www.daemonology.net/2007-08.html
[115]: http://www.daemonology.net/2007-06.html
[116]: http://www.daemonology.net/2007-05.html
[117]: http://www.daemonology.net/2007-03.html
[118]: http://www.daemonology.net/2007-02.html
[119]: http://www.daemonology.net/2007-01.html
[120]: http://www.daemonology.net/2006-11.html
[121]: http://www.daemonology.net/2006-10.html
[122]: http://www.daemonology.net/2006-09.html
[123]: http://www.daemonology.net/2006-08.html
[124]: http://www.daemonology.net/2006-07.html
[125]: http://www.daemonology.net/2006-06.html
[126]: http://www.daemonology.net/2006-05.html
[127]: http://www.daemonology.net/2006-04.html
[128]: http://www.daemonology.net/2006-03.html
[129]: http://www.daemonology.net/2006-01.html
[130]: http://www.daemonology.net/2005-12.html
[131]: http://www.daemonology.net/2005-11.html
[132]: http://www.daemonology.net/2005-10.html
[133]: http://www.daemonology.net/2005-09.html
[134]: http://www.daemonology.net/2018.html
[135]: http://www.daemonology.net/2017.html
[136]: http://www.daemonology.net/2016.html
[137]: http://www.daemonology.net/2015.html
[138]: http://www.daemonology.net/2014.html
[139]: http://www.daemonology.net/2013.html
[140]: http://www.daemonology.net/2012.html
[141]: http://www.daemonology.net/2011.html
[142]: http://www.daemonology.net/2010.html
[143]: http://www.daemonology.net/2009.html
[144]: http://www.daemonology.net/2008.html
[145]: http://www.daemonology.net/2007.html
[146]: http://www.daemonology.net/2006.html
[147]: http://www.daemonology.net/2005.html
[148]: http://www.daemonology.net/blog/index.rss "RSS feed"

