Fork me on GitHub

BetterCrypto⋅org

Applied Crypto Hardening

FAQ

General

Why write another guide?

While there are already a couple of excellent guides out there which describe keylengths, algorithms and crypto parameters (see for example the ENISA paper http://www.enisa.europa.eu/activities/ identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report), none of them focuses on our target group (system administrators) who often need an easy, copy & paste recommendation.

I want to review the document. What do I need to do?

git clone the document, make changes, send us a pull request or a diff. Do not forget to add your name to src/reviewers.tex.

Who is invited to review the document?

Essentially everyone. The core group of editors consists of crypologists, computer scientists and sysadmins.

Where is the mailing list?

http://lists.cert.at/cgi-bin/mailman/listinfo/ach

Can anyone subscribe to the list?

Yes, the mailling list is open to the public.

I found a bug

Eeek, a bug! Get in touch on the mailing list so we can fix it!

A recommendation does not work for me

Please get in contact with us on the mailing list to discuss the problem. If you already have a solution, please send a pull request or a diff!

Contributions

Is there a style-guide for the text?

Yes, we try to follow the following rules:

  • since every commit is cross-checked, it helps to commit frequently with small changes. This is easier to read on our gitweb site.
  • For cipher suite strings: explicit enumeration of ciphers/hashes/MACs/etc. is better than implicit. The reasoning behind this rule is that the implicit settings such as !EXPORT might change over time during system upgrades and might be different between different operating systems and library versions.
  • If there is some consensus decision for cipher strings, you need to document the trade-offs, fallbacks and backward compatibility effects.
  • Make your decisions transparent and be open for discussion on the mailing list. Peer review is never a personal critique, it is the quality assurance process of this project.
  • Send diffs to the LaTeX source code to the mailing list or send a pull request.
  • Scope of the document: you might have a great idea what to include but it might not make it to the current version since it is currently out of scope. We expect to have multiple versions.

How do I use the git repositories?

Please see the git page for all things related to git!