⦗ Libraries ⦘  ⦗ Random Numbers ⦘  ⦗ Symmetric Encryption ⦘ 
⦗ Hashing ⦘  ⦗ Digital Signatures ⦘  ⦗ Message Authentication ⦘ 
⦗ Key Exchange / Hybrid Encryption ⦘ 

Ｋｅｙ　Ｄｅｒｉｖａｔｉｏｎ

⦗ Password Based ⦘  ⦗ Non-Password Based ⦘

Ｋｅｙ　Ｓｉｚｅ

⦗ Symmetric ⦘  ⦗ Asymmetric ⦘

Background

This document outlines recommendations for cryptographic algorithm choices and
parameters as well as important implementation details based on what I have
learned from reading about the subject and the consensus I have observed online.

Note that some knowledge of cryptography is required
to understand the terminology used in this guide.

Goal
My goal with these guidelines is to provide a resource that I wish I had
access to when I first started writing programs related to cryptography.

If this information helps prevent even just one vulnerability, then I consider it time well spent.

Acknowledgments

These guidelines were inspired by:

This guide distinguishes itself through mentions of newer algorithms,
justifications for algorithm recommendations whilst also offering
important information on how to use them correctly.

Disclaimer

I’m a psychology undergraduate with an interest in applied cryptography,
not an experienced cryptographer.

I primarily have experience with Libsodium
since that’s what I’ve used for my projects,
but I’ve also reported some security
vulnerabilities related to cryptography.

Most experienced cryptographers don’t have the time to write things like this,
and the following information is freely available online or in books, so whilst
more experience would be beneficial,

I’m trying my best to provide accurate information that can be fact checked.


If I’ve made a mistake, please Contact Me to get it fixed.



Note that the rankings are based on:


Such protocols and recommended practices make for the best guidelines
because they’ve been approved by experienced professionals.

General Guidance


Research

Research, Research, Research!

You often don’t need to know how cryptographic algorithms
work under the hood to implement them correctly, just like
how you don’t need to know how a car works to drive.

However, you need to know enough about what you’re trying to do,
which requires looking up relevant information online or in books,
reading the documentation for the cryptographic library you’re using,
RFC standards, helpful blog posts and guides like this one.

Furthermore, reading books about the subject in general will be beneficial,
again like how knowing about cars can help if you break down.

For a list of great resources, check out my How to Learn About Cryptography blog post.


Test

And Test Again

It’s your responsibility to get things right the first time around
to the best of your ability rather than relying on peer reviews.

Therefore, I strongly recommend always reading over security sensitive
code at least twice and testing it to ensure that it’s operating as expected.
↳ Checking code line by line using a debugger, using test vectors, ...


Peer Reviews

Are Great But Often Don’t Happen

Unless your project is popular, you have a bug bounty program with cash
rewards, or what you’re developing is for an organization, very few people,
perhaps none at all, will look through the code to find and report vulnerabilities.

Similarly, receiving funding for a code audit will probably be near impossible.


Custom Algorithms

Please don’t create your own custom cryptographic algorithms for use in production

This is like flying a Boeing 747 without a pilot license but worse because even experienced
cryptographers design insecure algorithms, which is why cryptographic algorithms are
thoroughly analyzed by a large number of cryptanalysts, usually as part of a Competition .

By contrast, you rarely see experienced airline pilots crashing planes.

The only exception to this rule is implementing something
like Encrypt ➜ MAC with secure, existing cryptographic
algorithms when you know what you’re doing.


Recoding Algorithms

Please don’t recreate existing cryptographic algorithms for use in production

Cryptographic libraries provide access to these algorithms for you to prevent people
from making mistakes that cause vulnerabilities and to offer good performance.

Whilst a select few algorithms are relatively simple to implement, like HKDF,
many aren’t and require a great deal of experience to implement correctly.

It also doesn’t help that most academic papers and reference
implementations are quite difficult to understand.

Concluding Remarks

I believe there are three main areas of improvement when it comes
to individuals with experience in cryptography helping developers.


Cryptographic Libraries

Should Be Better

Most don’t make it easy to use cryptography safely (they support insecure
algorithms, require nonces, etc) and have Horrible Documentation .


This shouldn’t be the case, and there really should be greater uproar about this.



Stop Saying

Don't roll your own crypto


Repeating this phrase doesn’t help anyone.


Instead educate developers about how to do things properly, whether that be by:


It’s not a crime to implement Encrypt ➜ MAC,
and even when someone writes a custom cipher,
you should explain why that’s not a good idea
↳professional cryptographers still design insecure algorithms


Peer Reviews

Should Be Done More Often


It’s often:


Whilst developers who fail to do any reading related to cryptography
obviously deserve criticism, Even Experienced Professionals Make Mistakes.

Simple peer review, using the search on GitHub for things like HMAC and ECB,
helps catch things that are easy to spot, and more thorough peer review helps
catch things that even someone experienced Might Have Missed.

If something seems dodgy, then you should investigate if possible.



Thank you

For reading this guide, if you found it useful, consider visiting the Original Git .

I hope you liked my edits / formatting

Please consider sharing This Version or the Original so others can find them easier.