April 16, 2018 at 11:44Correct cryptography answers: 2018
Translation of the article by Latacora
The literature and the most sophisticated modern systems have the “best” answers to many questions. If you are developing embedded applications, you are encouraged to use STROBE and the trendy modern cryptographic stack to authenticate completely from single SHA-3-like sponge functions . It is advised to use NOISE to develop a secure transport protocol with the formation of a common authentication key (AKE). Speaking of AKE, there are about 30 different AKE passwords to choose from.
But if you are a developer, not a cryptographer, then you should not do anything like that. You should stick to simple and ordinary solutions that are easy to analyze - “boring,” as people at Google TLS say.
Percival, 2009: AES-CTR with HMAC.
Ptacek, 2015: (1) default settings NaCl / libsodium; (2) ChaCha20-Poly1305 or (3) AES-GCM.
Latacora, 2018: KMS or XSalsa20 + Poly1305 Required
if: you hide information from users or from the network.
If it’s convenient for you to use KMS, the hardware security module of Amazon (or Google), then use KMS. If you could use KMS, but encryption is a fun weekend project to save money on KMS, then definitely use KMS. If you encrypt simple secrets, like API tokens for your startup application, use the SSM Parameter Store, i.e. KMS. You do not need to understand how KMS works.
Otherwise, you would ideally want to getAEAD : authenticated encryption with attached data (option for authenticated clear text headers).
The main way to get authenticated encryption is to use a stream cipher (usually AES in CTR mode) with a polynomial MAC (message authentication code, cryptographic CRC).
In all these mainstream solutions, you will encounter one problem: nonce: number that can only be used once - a number that can be used once. You need to come up with a unique (usually random) number for each thread that will never be reused. The easiest way to generate nonses is from a safe random number generator, so you need a simple circuit for this.
Nons are especially important for AES-GCM, the most popular encryption mode. Unfortunately, it is especially difficult to implement them with AES-GCM: here we are balancing on the border of the safe use of random non-numbers.
Therefore, we recommend the use of XSalsa20-Poly1305. This is a variation of ChaPoly constructs, which together are the most common encryption constructs after AES-GCM. Take XSalsa20-Poly1305 in libsodium or NaCl.
The advantage of XSalsa20 over ChaCha20 and Salsa20 is that XSalsa supports advanced non-rules. They are big enough, so you just create a big long random nons for each thread - and don't worry about how many threads need to be encrypted.
There are NMR or MRAE schemes that promise some degree of security even if the nons are mishandled; these include GCM-SIV (actually all SIV) and Deoxys-II, CAESAR contest finalist. They are interesting, but in reality no one supports and uses them yet, and with extended nons, the gain in security is hardly distinguishable. These are not very boring schemes. In the meantime, we need to remain boring.
Avoid: AES-CBC, AES-CTR in itself, block ciphers with 64-bit blocks - especially the inexplicably popular Blowfish, avoid OFB mode. Never use an RC4 that is comically broken.
Percival, 2009: use 256-bit keys.
Ptacek, 2015: Use 256-bit keys.
Latacora, 2018: go ahead, use 256-bit keys.
It is necessary in case: you use cryptography.
But remember: your AES key will be much less likely to break than your public key pair, so the size of the latter should be larger if you are going to focus on this.
Avoid: constructions with huge keys, encryption “cascades”, key sizes up to 128 bits.
Percival, 2009: Use HMAC.
Ptacek, 2015: Yes, use the HMAC.
Latacora, 2018: still HMAC.
It is necessary if: you protect the API, encrypt session cookies or encrypt user data, but, contrary to the advice of the doctor, do not use the AEAD construct.
If you have authentication without encryption, as with API requests, do not do anything complicated. There is a class of cryptorealization bugs due to the way data is sent to the MAC, so if you are developing a new system from scratch, google “crypto canonicalization bugs”. In addition, use the safe comparison function.
If you use HMAC, then there are advisers who will tell you that SHA3 (and truncated SHA2 hashes) can do KMAC, that is, you can just chain the key and data, hash them and be safe. This means that in theory, the HMAC does unnecessary extra work with SHA-3 or truncated SHA-2. But who cares? Imagine HMAC as a cheap insurance for your design in case someone switches to an unchecked SHA-2.
Avoid: do-it-yourself “hash with key” constructions, HMAC-MD5, HMAC-SHA1, complex polynomial MAC, encrypted hashes, CRC.
Percival, 2009: Use SHA256 (SHA-2).
Ptacek, 2015: Use SHA-2.
Latacora, 2018: still SHA-2.
It is necessary in case: it is always necessary.
If it suits you: use SHA-512/256, which truncates the output and avoids attacks by lengthening the message.
We still think that upgrading from SHA-2 to SHA-3 is less likely than to something faster than SHA-3. And since SHA-2 still looks great, feel comfortable and stay on SHA-2.
Avoid: SHA-1, MD5, MD6.
Percival, 2009: Use 256-bit random numbers.
Ptacek, 2015: Use 256-bit random numbers.
Latacora, 2018: use 256-bit random numbers.
It is necessary in case: it is always necessary.
From / dev / urandom.
Avoid: random number generators from user space, RNG from OpenSSL, havaged, prngd, egd, / dev / random.
Percival, 2009: scrypt or PBKDF2.
Ptacek, 2015: in order of preference scrypt, bcrypt, and if nothing else is available, then PBKDF2.
Latacora, 2018: in order of preference scrypt, argon2, bcrypt, and if nothing else is available, then PBKDF2.
It is necessary if: you accept passwords from users or somewhere in the system there are human-readable secret keys.
No, in fact: you can throw a dart and choose one of the listed options at random. Technically, argon2 and scrypt are significantly better than bcrypt, which is much better than PBKDF2. But in practice, the main thing is that you use a truly secure password hash, and not which one.
Do not create complex password hashing schemes.
Avoid: SHA-3, naked SHA-2, SHA-1, MD5.
Percival, 2009: Use RSAES-OAEP with SHA256 and MGF1 + SHA256.
Ptacek, 2015: use NaCl / libsodium (box / crypto_box).
Latacora, 2018: use NaCl / libsodium (box / crypto_box).
It is necessary if: it is required to encrypt the message for many different people, including strangers, and they should be able to receive the message asynchronously, as in e-mail, and then decrypt it offline. This is a rather specific use case.
Of all the cryptographic "correct answers", this is hardly what you will receive on your own. Do not use freelance public key encryption and low-level cryptographic libraries like OpenSSL or BouncyCastle.
Here are a few reasons why you should stop using RSA and switch to elliptical curves:
NaCl uses Curve25519 (the most popular modern elliptic curve system, carefully designed to eliminate several classes of attacks against standard NIST curves) in combination with the ChaPoly AEAD scheme. Your programming language has NaCl bindings (or, in the case of Go, its own library implementation) - use them. Do not try to assemble everything yourself.
Do not use RSA.
Avoid: systems developed after 2015 using RSA, RSA-PKCS1v15, RSA, ElGamal, I don’t know, Merkle-Hellman knapsacks? Just avoid RSA.
Percival, 2009: Use RSASSA-PSS with SHA256, then MGF1 + SHA256.
Ptacek, 2015: Use NaCl, Ed25519 or RFC6979.
Latacora, 2018: use NaCl or Ed25519.
It is necessary if: you are developing a new cryptocurrency. Or a signature system for Ruby Gems or Vagrant pictures, or a DRM scheme where you need to use the same secret key to verify the authenticity of a series of files arriving at random times offline. Or you create a transport for encrypted messages.
The statements from the previous answer are completely suitable for this point.
Over the past 10 years, the two most important cases of using asymmetric signatures have been cryptocurrencies and key negotiation protocols of perfect direct secrecy, as in ECDHE-TLS. The dominant algorithms for these cases are based on elliptic curves. Beware of new systems using RSA signatures.
In the past few years, there has been a significant shift from conventional DSA signatures to abusive, “deterministic” signature schemes, the best examples of which are EdDSA and RFC6979. You can think of them as “user-protected” responses to the Playstation 3 ECDSA vulnerability, where reusing a random number produced secret keys. Prefer deterministic signatures to any other signature schemes.
Ed25519 from the default settings, NaCl / libsodium is now the most popular public key signing scheme outside of Bitcoin. It is resistant to abuse and carefully designed in other respects. It should not be independently designed; take the implementation from NaCl.
Avoid: RSA-PKCS1v15, RSA, ECDSA, DSA; indeed, ordinary DSA and ECDSA should be avoided especially.
Percival, 2009: work on 2048-bit group # 14 with generator 2.
Ptacek, 2015: probably still DH-2048 or NaCl.
Latacora, 2018: probably nothing. Or use Curve25519.
If: you are developing an encrypted transport or messaging system that someday strangers will use, and therefore static AES keys are not suitable.
The 2015 version of this document confused everyone to hell.
Part of the problem is that our “right answers” are the answer to the “right answers” by Colin Percival, and he included the answer about Diffie-Hellman, as if it were a normal protocol for developers. In fact, developers simply do not need to freelance create their own encrypted transports. To get an idea of the complexity of this problem, read the Noise Protocol Framework documentation . If you are exchanging keys using the DH protocol, then you probably want to generate shared authentication keys (AKEs) that resist key compromise attacks by disguising as a legitimate user (key compromise impersonation, KCI). So the primitive for DH is not the only serious security issue.
But it doesn’t matter.
Everything remains the same: if you can just use NaCl, use NaCl. You don’t even have to care about what NaCl does. This is the meaning of NaCl.
Otherwise, use Curve25519. There are libraries for almost every language. In 2015, we were worried about encouraging people to write their own Curve25519 libraries, reflecting on Javascript bignum implementations. But in reality, the essence of Curve25519 is partly that the entire curve is carefully selected to minimize implementation errors. Do not write your own! In fact, just use Curve25519.
Do not implement ECDH with NIST curves, where you have to carefully check the points of the elliptic curves before using them for calculations to avoid leakage of secrets. This attack is very simple to implement: simpler than padding oracle on CBC, and much more destructive.
The 2015 document contained a paragraph on the preference of DH-1024 over surface curve libraries. And you know what? The argument is still relevant. He is relevant and stupid. The choice of “DH-1024 or surface curve library” can be compared to the choice of “Use Blowfish or IDEA”. There should not be such a choice. Use Curve25519.
Avoid: conventional DH, SRP, J-PAKE, handshakes and alignment complex key agreement schemes, using only a block cipher
Percival, 2009: Use OpenSSL.
Ptacek, 2015: Remains OpenSSL or BoringSSL, if possible. Or just use AWS ELB.
Latacora 2018: Use AWS ALB / ELB or OpenSSL with LetsEncrypt.
It is necessary in case: you have a site.
If you can pay AWS so you don’t care about this problem, we recommend that you do it.
Otherwise, there was a dark period between 2010 and 2016, when OpenSSL might not have been the right answer, but that time has passed. OpenSSL is better, and more importantly, OpenSSL is ready to report and respond to vulnerabilities found.
Using something other than OpenSSL means drastically complicating your system for the sake of a small, zero, or even negative security benefit. So keep it simple.
Speaking of the simple: LetsEncrypt is a free and automated service. Set up a cron job for regular certificate collection and testing.
Avoid: unusual TLS libraries PolarSSL, GnuTLS and MatrixSSL.
Percival, 2009: Distribute the server’s public RSA key with client code and do not use SSL.
Ptacek, 2015: Use OpenSSL or BoringSSL if you can. Or just use AWS ELB.
Latacora 2018: Use AWS ALB / ELB or OpenSSL with LetsEncrypt.
It is necessary if: the previous recommendations on cryptography with a public key were relevant for you.
It seems a little crazy to recommend TLS, given the latest story:
This is why you should still use TLS for your own transport protocol:
Avoid: design your own transport encryption protocol, which is a really difficult engineering problem; Use TLS in the default configuration (for example, c
Percival, 2009: Use Tarsnap.
Ptacek, 2015: Use Tarsnap.
Latacora, 2018: Store encrypted PMAC-SIV arc files in S3 and save backup fingerprints to the ERC20-compatible blockchain.
It is necessary in case: you are worried about backups.
Just a joke. Still use Tarsnap.
We announce the action “More cyber defense for sports”!
GlobalSign joins the celebration of the most ambitious event of all athletes and football fans - WORLD FOOTBALL CHAMPIONSHIP 2018 and GIVES 1 YEAR OF SSL PROTECTION! *
Promotion conditions:
* When you purchase any one - year SSL certificate of DV, OV or EV level, you receive a second year as a gift .
• The promotion applies to all sports-related websites.
• The promotion is valid only for new orders and does not apply to partners.
• To take advantage of the offer, send a request on the website with the promotional code: SL003HBFR .
The promotion will last until July 15, 2018.
You can get additional information on the campaign from GlobalSign Russia managers by phone: +7 (499) 678 2210.
MORE PROTECTION with GlobalSign!
The literature and the most sophisticated modern systems have the “best” answers to many questions. If you are developing embedded applications, you are encouraged to use STROBE and the trendy modern cryptographic stack to authenticate completely from single SHA-3-like sponge functions . It is advised to use NOISE to develop a secure transport protocol with the formation of a common authentication key (AKE). Speaking of AKE, there are about 30 different AKE passwords to choose from.
But if you are a developer, not a cryptographer, then you should not do anything like that. You should stick to simple and ordinary solutions that are easy to analyze - “boring,” as people at Google TLS say.
Correct cryptography answers
Data encryption
Percival, 2009: AES-CTR with HMAC.
Ptacek, 2015: (1) default settings NaCl / libsodium; (2) ChaCha20-Poly1305 or (3) AES-GCM.
Latacora, 2018: KMS or XSalsa20 + Poly1305 Required
if: you hide information from users or from the network.
If it’s convenient for you to use KMS, the hardware security module of Amazon (or Google), then use KMS. If you could use KMS, but encryption is a fun weekend project to save money on KMS, then definitely use KMS. If you encrypt simple secrets, like API tokens for your startup application, use the SSM Parameter Store, i.e. KMS. You do not need to understand how KMS works.
Otherwise, you would ideally want to getAEAD : authenticated encryption with attached data (option for authenticated clear text headers).
The main way to get authenticated encryption is to use a stream cipher (usually AES in CTR mode) with a polynomial MAC (message authentication code, cryptographic CRC).
In all these mainstream solutions, you will encounter one problem: nonce: number that can only be used once - a number that can be used once. You need to come up with a unique (usually random) number for each thread that will never be reused. The easiest way to generate nonses is from a safe random number generator, so you need a simple circuit for this.
Nons are especially important for AES-GCM, the most popular encryption mode. Unfortunately, it is especially difficult to implement them with AES-GCM: here we are balancing on the border of the safe use of random non-numbers.
Therefore, we recommend the use of XSalsa20-Poly1305. This is a variation of ChaPoly constructs, which together are the most common encryption constructs after AES-GCM. Take XSalsa20-Poly1305 in libsodium or NaCl.
The advantage of XSalsa20 over ChaCha20 and Salsa20 is that XSalsa supports advanced non-rules. They are big enough, so you just create a big long random nons for each thread - and don't worry about how many threads need to be encrypted.
There are NMR or MRAE schemes that promise some degree of security even if the nons are mishandled; these include GCM-SIV (actually all SIV) and Deoxys-II, CAESAR contest finalist. They are interesting, but in reality no one supports and uses them yet, and with extended nons, the gain in security is hardly distinguishable. These are not very boring schemes. In the meantime, we need to remain boring.
Avoid: AES-CBC, AES-CTR in itself, block ciphers with 64-bit blocks - especially the inexplicably popular Blowfish, avoid OFB mode. Never use an RC4 that is comically broken.
Symmetric Key Length
Percival, 2009: use 256-bit keys.
Ptacek, 2015: Use 256-bit keys.
Latacora, 2018: go ahead, use 256-bit keys.
It is necessary in case: you use cryptography.
But remember: your AES key will be much less likely to break than your public key pair, so the size of the latter should be larger if you are going to focus on this.
Avoid: constructions with huge keys, encryption “cascades”, key sizes up to 128 bits.
Symmetric Signatures
Percival, 2009: Use HMAC.
Ptacek, 2015: Yes, use the HMAC.
Latacora, 2018: still HMAC.
It is necessary if: you protect the API, encrypt session cookies or encrypt user data, but, contrary to the advice of the doctor, do not use the AEAD construct.
If you have authentication without encryption, as with API requests, do not do anything complicated. There is a class of cryptorealization bugs due to the way data is sent to the MAC, so if you are developing a new system from scratch, google “crypto canonicalization bugs”. In addition, use the safe comparison function.
If you use HMAC, then there are advisers who will tell you that SHA3 (and truncated SHA2 hashes) can do KMAC, that is, you can just chain the key and data, hash them and be safe. This means that in theory, the HMAC does unnecessary extra work with SHA-3 or truncated SHA-2. But who cares? Imagine HMAC as a cheap insurance for your design in case someone switches to an unchecked SHA-2.
Avoid: do-it-yourself “hash with key” constructions, HMAC-MD5, HMAC-SHA1, complex polynomial MAC, encrypted hashes, CRC.
Hash algorithm
Percival, 2009: Use SHA256 (SHA-2).
Ptacek, 2015: Use SHA-2.
Latacora, 2018: still SHA-2.
It is necessary in case: it is always necessary.
If it suits you: use SHA-512/256, which truncates the output and avoids attacks by lengthening the message.
We still think that upgrading from SHA-2 to SHA-3 is less likely than to something faster than SHA-3. And since SHA-2 still looks great, feel comfortable and stay on SHA-2.
Avoid: SHA-1, MD5, MD6.
Random ID
Percival, 2009: Use 256-bit random numbers.
Ptacek, 2015: Use 256-bit random numbers.
Latacora, 2018: use 256-bit random numbers.
It is necessary in case: it is always necessary.
From / dev / urandom.
Avoid: random number generators from user space, RNG from OpenSSL, havaged, prngd, egd, / dev / random.
Password Processing
Percival, 2009: scrypt or PBKDF2.
Ptacek, 2015: in order of preference scrypt, bcrypt, and if nothing else is available, then PBKDF2.
Latacora, 2018: in order of preference scrypt, argon2, bcrypt, and if nothing else is available, then PBKDF2.
It is necessary if: you accept passwords from users or somewhere in the system there are human-readable secret keys.
No, in fact: you can throw a dart and choose one of the listed options at random. Technically, argon2 and scrypt are significantly better than bcrypt, which is much better than PBKDF2. But in practice, the main thing is that you use a truly secure password hash, and not which one.
Do not create complex password hashing schemes.
Avoid: SHA-3, naked SHA-2, SHA-1, MD5.
Asymmetric Encryption
Percival, 2009: Use RSAES-OAEP with SHA256 and MGF1 + SHA256.
Ptacek, 2015: use NaCl / libsodium (box / crypto_box).
Latacora, 2018: use NaCl / libsodium (box / crypto_box).
It is necessary if: it is required to encrypt the message for many different people, including strangers, and they should be able to receive the message asynchronously, as in e-mail, and then decrypt it offline. This is a rather specific use case.
Of all the cryptographic "correct answers", this is hardly what you will receive on your own. Do not use freelance public key encryption and low-level cryptographic libraries like OpenSSL or BouncyCastle.
Here are a few reasons why you should stop using RSA and switch to elliptical curves:
- RSA (and DH) are pulling you toward “backward compatibility” with unsafe systems, making protocol down attacks possible.
- RSA asks for encryption directly using its public key primitive, which is usually against the interests of users.
- RSA has too many settings. In modern systems with elliptic curves like Curve25519, everything is preconfigured for security.
NaCl uses Curve25519 (the most popular modern elliptic curve system, carefully designed to eliminate several classes of attacks against standard NIST curves) in combination with the ChaPoly AEAD scheme. Your programming language has NaCl bindings (or, in the case of Go, its own library implementation) - use them. Do not try to assemble everything yourself.
Do not use RSA.
Avoid: systems developed after 2015 using RSA, RSA-PKCS1v15, RSA, ElGamal, I don’t know, Merkle-Hellman knapsacks? Just avoid RSA.
Asymmetric Signatures
Percival, 2009: Use RSASSA-PSS with SHA256, then MGF1 + SHA256.
Ptacek, 2015: Use NaCl, Ed25519 or RFC6979.
Latacora, 2018: use NaCl or Ed25519.
It is necessary if: you are developing a new cryptocurrency. Or a signature system for Ruby Gems or Vagrant pictures, or a DRM scheme where you need to use the same secret key to verify the authenticity of a series of files arriving at random times offline. Or you create a transport for encrypted messages.
The statements from the previous answer are completely suitable for this point.
Over the past 10 years, the two most important cases of using asymmetric signatures have been cryptocurrencies and key negotiation protocols of perfect direct secrecy, as in ECDHE-TLS. The dominant algorithms for these cases are based on elliptic curves. Beware of new systems using RSA signatures.
In the past few years, there has been a significant shift from conventional DSA signatures to abusive, “deterministic” signature schemes, the best examples of which are EdDSA and RFC6979. You can think of them as “user-protected” responses to the Playstation 3 ECDSA vulnerability, where reusing a random number produced secret keys. Prefer deterministic signatures to any other signature schemes.
Ed25519 from the default settings, NaCl / libsodium is now the most popular public key signing scheme outside of Bitcoin. It is resistant to abuse and carefully designed in other respects. It should not be independently designed; take the implementation from NaCl.
Avoid: RSA-PKCS1v15, RSA, ECDSA, DSA; indeed, ordinary DSA and ECDSA should be avoided especially.
Diffie - Hellman
Percival, 2009: work on 2048-bit group # 14 with generator 2.
Ptacek, 2015: probably still DH-2048 or NaCl.
Latacora, 2018: probably nothing. Or use Curve25519.
If: you are developing an encrypted transport or messaging system that someday strangers will use, and therefore static AES keys are not suitable.
The 2015 version of this document confused everyone to hell.
Part of the problem is that our “right answers” are the answer to the “right answers” by Colin Percival, and he included the answer about Diffie-Hellman, as if it were a normal protocol for developers. In fact, developers simply do not need to freelance create their own encrypted transports. To get an idea of the complexity of this problem, read the Noise Protocol Framework documentation . If you are exchanging keys using the DH protocol, then you probably want to generate shared authentication keys (AKEs) that resist key compromise attacks by disguising as a legitimate user (key compromise impersonation, KCI). So the primitive for DH is not the only serious security issue.
But it doesn’t matter.
Everything remains the same: if you can just use NaCl, use NaCl. You don’t even have to care about what NaCl does. This is the meaning of NaCl.
Otherwise, use Curve25519. There are libraries for almost every language. In 2015, we were worried about encouraging people to write their own Curve25519 libraries, reflecting on Javascript bignum implementations. But in reality, the essence of Curve25519 is partly that the entire curve is carefully selected to minimize implementation errors. Do not write your own! In fact, just use Curve25519.
Do not implement ECDH with NIST curves, where you have to carefully check the points of the elliptic curves before using them for calculations to avoid leakage of secrets. This attack is very simple to implement: simpler than padding oracle on CBC, and much more destructive.
The 2015 document contained a paragraph on the preference of DH-1024 over surface curve libraries. And you know what? The argument is still relevant. He is relevant and stupid. The choice of “DH-1024 or surface curve library” can be compared to the choice of “Use Blowfish or IDEA”. There should not be such a choice. Use Curve25519.
Avoid: conventional DH, SRP, J-PAKE, handshakes and alignment complex key agreement schemes, using only a block cipher
srand(time()).*.Website Security
Percival, 2009: Use OpenSSL.
Ptacek, 2015: Remains OpenSSL or BoringSSL, if possible. Or just use AWS ELB.
Latacora 2018: Use AWS ALB / ELB or OpenSSL with LetsEncrypt.
It is necessary in case: you have a site.
If you can pay AWS so you don’t care about this problem, we recommend that you do it.
Otherwise, there was a dark period between 2010 and 2016, when OpenSSL might not have been the right answer, but that time has passed. OpenSSL is better, and more importantly, OpenSSL is ready to report and respond to vulnerabilities found.
Using something other than OpenSSL means drastically complicating your system for the sake of a small, zero, or even negative security benefit. So keep it simple.
Speaking of the simple: LetsEncrypt is a free and automated service. Set up a cron job for regular certificate collection and testing.
Avoid: unusual TLS libraries PolarSSL, GnuTLS and MatrixSSL.
Client Server Application Security
Percival, 2009: Distribute the server’s public RSA key with client code and do not use SSL.
Ptacek, 2015: Use OpenSSL or BoringSSL if you can. Or just use AWS ELB.
Latacora 2018: Use AWS ALB / ELB or OpenSSL with LetsEncrypt.
It is necessary if: the previous recommendations on cryptography with a public key were relevant for you.
It seems a little crazy to recommend TLS, given the latest story:
- Logjam DH attack on session keys
- FREAK attack on RSA_EXPORT
- POODLE attack on oracle CBC
- Fiasco RC4
- CRIME attack on compression algorithm
- Lucky13 time attack of padding oracle type on CBC ciphers
- BEAST attack on CBC cipher initialization vector
- Heartbleed
- TLS Reconciliation
- Triple handshakes
- Compromised Certificate Authorities
- DROWN attack
This is why you should still use TLS for your own transport protocol:
- In your own protocols, you do not have to depend on third-party certification authorities. You can even not use certification authorities at all (although it’s easy to set up your own); you can just use the whitelist of self-signed certificates - something like this SSH does by default.
- Since you are creating your own protocol, you can use the best TLS cipher suites: TLS 1.2+, Curve25519 and ChaPoly. This protects against most attacks on TLS. The reason that everyone does not do this is because backward compatibility is needed, but it is not needed in the native protocol.
- Many of these attacks work only against browsers, because the victim must accept and execute Javascript controlled by the attacker in order to generate duplicate known / matched texts.
Avoid: design your own transport encryption protocol, which is a really difficult engineering problem; Use TLS in the default configuration (for example, c
curl) use curl, IPSEC.Online backups
Percival, 2009: Use Tarsnap.
Ptacek, 2015: Use Tarsnap.
Latacora, 2018: Store encrypted PMAC-SIV arc files in S3 and save backup fingerprints to the ERC20-compatible blockchain.
It is necessary in case: you are worried about backups.
Just a joke. Still use Tarsnap.
We announce the action “More cyber defense for sports”!
GlobalSign joins the celebration of the most ambitious event of all athletes and football fans - WORLD FOOTBALL CHAMPIONSHIP 2018 and GIVES 1 YEAR OF SSL PROTECTION! *
Promotion conditions:
* When you purchase any one - year SSL certificate of DV, OV or EV level, you receive a second year as a gift .
• The promotion applies to all sports-related websites.
• The promotion is valid only for new orders and does not apply to partners.
• To take advantage of the offer, send a request on the website with the promotional code: SL003HBFR .
The promotion will last until July 15, 2018.
You can get additional information on the campaign from GlobalSign Russia managers by phone: +7 (499) 678 2210.
MORE PROTECTION with GlobalSign!