Correct cryptographic answers: 2018
Translation of an article by Latacora
In the literature and the most complex modern systems there are "best" answers to many questions. If you are developing embedded applications, you are advised to use STROBE and a modern, modern cryptographic stack for authentication entirely from single SHA-3-like sponge functions . It is advised to use NOISE to develop a secure transport protocol with common authentication key generation (AKE). Speaking of AKE, there are about 30 different AKE passwords to choose from.
But if you are a developer, not a cryptographer, you should not do anything like that. You should stick to simple and simple solutions that are easy to analyze - “boring,” as people at Google TLS say.
Percival, 2009: AES-CTR with HMAC.
')
Ptacek, 2015: (1) NaCl / libsodium default settings; (2) ChaCha20-Poly1305 or (3) AES-GCM.
Latacora, 2018: KMS or XSalsa20 + Poly1305
Needed if: you hide information from users or from the network.
If you are comfortable using KMS, an Amazon (or Google) hardware security module, use KMS. If you could use KMS, but encryption is a fun project for the weekend, saving money on KMS, then use KMS for sure. If you encrypt simple secrets, such as API tokens for your application in a startup, use the SSM Parameter Store, that is, KMS. You do not need to understand how KMS works.
Otherwise, you would ideally like to receive AEAD : authenticated encryption with attached data (option for authenticated plain 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 - these are nonses (nonce: number 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 stream that will never be reused. The easiest way to generate nonses is from a safe random number generator, so you need a simple scheme for this.
The nets are especially important for AES-GCM, the most popular encryption mode. Unfortunately, it is especially difficult to implement them just with AES-GCM: here we are balancing on the border of safe use of random nons.
Therefore, we recommend using 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 nons. They are big enough, so you just create a big long random nones for each stream — and you don’t worry about how many threads you want to encrypt.
There are NMR or MRAE schemes that promise some degree of security even when mistreated with nonses; These include GCM-SIV (actually all SIV) and Deoxys-II, a finalist for the CAESAR competition. They are interesting, but in reality no one yet supports or uses them, and with advanced nones, the security gain is barely visible. These are not very boring schemes. And we still need to stay boring.
Avoid: AES-CBC, AES-CTR itself, block ciphers with 64-bit blocks - especially the inexplicably popular Blowfish, avoid OFB mode. Never use RC4, which is comically broken.
Percival, 2009: Use 256-bit keys.
Ptacek, 2015: Use 256-bit keys.
Latacora, 2018: Forward, use 256-bit keys.
Needed if: you are using cryptography.
But remember: your AES key will break with much less probability than your public key pair, so the size of the latter should be larger if you are going to dwell on it.
Avoid: constructions with huge keys, cryptographic "cascades", key sizes up to 128 bits.
Percival, 2009: Use the HMAC.
Ptacek, 2015: Yes, use the HMAC.
Latacora, 2018: still HMAC.
This is necessary if: you protect the API, encrypt session cookies, or encrypt user data, but, contrary to the advice of the doctor, you 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 crypto-implementation bugs because of how the data is sent to the MAC, so if you are developing a new system from scratch, google the “crypto canonicalization bugs”. Also, use the safe comparison feature.
If you use HMAC, then there are advisers who will tell you that SHA3 (and truncated SHA2 hashes) can make KMAC, that is, you can simply concatenate the key and the data, hash them and be safe. This means that, in theory, HMAC performs unnecessary additional 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 uncut SHA-2.
Avoid: homemade 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 you like: use SHA-512/256, which truncates the output and dodges attacks by lengthening the message.
We still think that upgrading from SHA-2 to SHA-3 is less likely than something faster than SHA-3. And since SHA-2 still looks great, feel comfortable and stay at 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 in case: 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 at random one of these options. 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, bare 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).
Needed if: you want to encrypt the message for many different people, including strangers, and they should be able to accept the message asynchronously, as in an e-mail, and then decrypt it offline. This is a rather specific use case.
Of all the cryptographic "correct answers", this one is unlikely to get on your own. Do not use freelance public key encryption and low-level cryptographic libraries like OpenSSL or BouncyCastle.
Here are some reasons why you should stop using RSA and switch to elliptic curves:
NaCl uses the Curve25519 (the most popular modern system on elliptic curves, 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, your own library implementation) - use them. Do not try to collect everything yourself.
Do not use RSA.
Avoid: systems developed after 2015 using RSA, RSA-PKCS1v15, RSA, ElGamal, I do not know, Merkl - Hellman backpacks? 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.
Needed 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 authenticate a series of files coming at random times using the same secret key. Or you create a transport for encrypted messages.
The statements from the previous answer are fully applicable to this item.
Over the past 10 years, the two most important cases of using asymmetric signatures are cryptocurrency and the key agreement protocols of perfect forward secrecy, as in ECDHE-TLS. The dominant algorithms for these cases are based on elliptic curves. Be wary of new systems using RSA signatures.
In the past few years, there has been a significant transition from conventional DSA signatures to resistant against the abuse of “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 the reuse of a random number produced secret keys. Prefer deterministic signatures to any other signature schemes.
Ed25519 from the default NaCl / libsodium settings is now the most popular public key signature scheme outside of Bitcoin. It is resistant to abuse and carefully designed elsewhere. She too should not be self-designed; Take the implementation from NaCl.
Avoid: RSA-PKCS1v15, RSA, ECDSA, DSA; indeed, especially DSA and ECDSA should be avoided.
Percival, 2009: Work on the 2048-bit group # 14 with generator 2.
Ptacek, 2015: probably still DH-2048 or NaCl.
Latacora, 2018: probably nothing. Or use Curve25519.
This is necessary if: you are developing an encrypted transport or messaging system that strangers will ever use, and therefore AES static keys are not appropriate.
The 2015 version of this document has confused everyone to hell.
Part of the problem is that our "correct answers" is the answer to Colin Percival's "correct answers," and he included the answer about Diffie-Hellman, as if this is a common protocol for developers. In fact, developers simply do not have to freelance to create their own encrypted transports. To get an idea of ​​the complexity of this issue, read the Noise Protocol Framework documentation. If you are performing DH key exchange, you probably want to generate Shared Authentication Keys (AKE) that counter attacks with key compromise by disguising as a legitimate user (key compromise impersonation, KCI). So the primitive for DH is not the only serious security issue.
But never mind.
Everything remains the same: if you can just use NaCl, use NaCl. You don’t even have to worry 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 the implementations of the Javascript bignum. But in reality, the essence of Curve25519 partly lies in the fact that the entire curve is carefully selected to minimize implementation errors. Do not write your own! In fact, just use Curve25519.
Do not embed ECDH with NIST curves, where you will have to carefully check the elliptic curve points before using them for calculations to avoid secrets leaking. This attack is very simple to implement: easier than the padding oracle on the CBC, and much more destructive.
The 2015 document contained a clause about DH-1024 preferences 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 with the choice of “Use Blowfish or IDEA”. This choice should not be. Use Curve25519.
Avoid: normal DH, SRP, J-PAKE, handshakes and coordination, complex key agreement schemes using only block ciphers,
Percival, 2009: use OpenSSL.
Ptacek, 2015: OpenSSL or BoringSSL remains, 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 website.
If you can pay AWS to not care about this problem, then we recommend to do it.
Otherwise, there was a dark period between 2010 and 2016, when OpenSSL might not have been the right answer, but that time had passed. OpenSSL is better, and, more importantly, OpenSSL is ready to report and respond to vulnerabilities found.
Using something other than OpenSSL means making your system very difficult for a small, zero, or even negative security benefit. So be simple.
Speaking of simple: LetsEncrypt is a free and automated service. Set up a cron job for regularly collecting certificates and testing.
Avoid: Unusual TLS PolarSSL, GnuTLS and MatrixSSL libraries.
Percival, 2009: Distribute the server's public RSA key with the 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.
Needed in case: the previous recommendations on public-key cryptography were relevant to 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 truly complex engineering problem; use TLS in the default configuration (for example, with
Percival, 2009: use Tarsnap.
Ptacek, 2015: Use Tarsnap.
Latacora, 2018: store the PMAC-SIV encrypted arc files in S3 and save fingerprint backups 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 to sports”!
GlobalSign joins the celebration of the most ambitious event of all athletes and football fans - WORLD FOOTBALL CHAMPIONSHIP 2018 and GIVEN 1 YEAR SSL PROTECTION! *
Terms of action:
* When you purchase any one - year DV-OV or EV -level SSL certificate , you get the second year as a gift.
• The promotion applies to all sites of sports.
• 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 promotion from GlobalSign Russia managers by phone: +7 (499) 678 2210.
MORE PROTECTION with GlobalSign!
In the literature and the most complex modern systems there are "best" answers to many questions. If you are developing embedded applications, you are advised to use STROBE and a modern, modern cryptographic stack for authentication entirely from single SHA-3-like sponge functions . It is advised to use NOISE to develop a secure transport protocol with common authentication key generation (AKE). Speaking of AKE, there are about 30 different AKE passwords to choose from.
But if you are a developer, not a cryptographer, you should not do anything like that. You should stick to simple and simple solutions that are easy to analyze - “boring,” as people at Google TLS say.
Correct cryptographic answers
Data encryption
Percival, 2009: AES-CTR with HMAC.
')
Ptacek, 2015: (1) NaCl / libsodium default settings; (2) ChaCha20-Poly1305 or (3) AES-GCM.
Latacora, 2018: KMS or XSalsa20 + Poly1305
Needed if: you hide information from users or from the network.
If you are comfortable using KMS, an Amazon (or Google) hardware security module, use KMS. If you could use KMS, but encryption is a fun project for the weekend, saving money on KMS, then use KMS for sure. If you encrypt simple secrets, such as API tokens for your application in a startup, use the SSM Parameter Store, that is, KMS. You do not need to understand how KMS works.
Otherwise, you would ideally like to receive AEAD : authenticated encryption with attached data (option for authenticated plain 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 - these are nonses (nonce: number 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 stream that will never be reused. The easiest way to generate nonses is from a safe random number generator, so you need a simple scheme for this.
The nets are especially important for AES-GCM, the most popular encryption mode. Unfortunately, it is especially difficult to implement them just with AES-GCM: here we are balancing on the border of safe use of random nons.
Therefore, we recommend using 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 nons. They are big enough, so you just create a big long random nones for each stream — and you don’t worry about how many threads you want to encrypt.
There are NMR or MRAE schemes that promise some degree of security even when mistreated with nonses; These include GCM-SIV (actually all SIV) and Deoxys-II, a finalist for the CAESAR competition. They are interesting, but in reality no one yet supports or uses them, and with advanced nones, the security gain is barely visible. These are not very boring schemes. And we still need to stay boring.
Avoid: AES-CBC, AES-CTR itself, block ciphers with 64-bit blocks - especially the inexplicably popular Blowfish, avoid OFB mode. Never use RC4, which is comically broken.
Symmetric key length
Percival, 2009: Use 256-bit keys.
Ptacek, 2015: Use 256-bit keys.
Latacora, 2018: Forward, use 256-bit keys.
Needed if: you are using cryptography.
But remember: your AES key will break with much less probability than your public key pair, so the size of the latter should be larger if you are going to dwell on it.
Avoid: constructions with huge keys, cryptographic "cascades", key sizes up to 128 bits.
Symmetric "signatures"
Percival, 2009: Use the HMAC.
Ptacek, 2015: Yes, use the HMAC.
Latacora, 2018: still HMAC.
This is necessary if: you protect the API, encrypt session cookies, or encrypt user data, but, contrary to the advice of the doctor, you 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 crypto-implementation bugs because of how the data is sent to the MAC, so if you are developing a new system from scratch, google the “crypto canonicalization bugs”. Also, use the safe comparison feature.
If you use HMAC, then there are advisers who will tell you that SHA3 (and truncated SHA2 hashes) can make KMAC, that is, you can simply concatenate the key and the data, hash them and be safe. This means that, in theory, HMAC performs unnecessary additional 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 uncut SHA-2.
Avoid: homemade hash with key constructions, HMAC-MD5, HMAC-SHA1, complex polynomial MAC, encrypted hashes, CRC.
Hashing 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 you like: use SHA-512/256, which truncates the output and dodges attacks by lengthening the message.
We still think that upgrading from SHA-2 to SHA-3 is less likely than something faster than SHA-3. And since SHA-2 still looks great, feel comfortable and stay at 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 handling
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 in case: 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 at random one of these options. 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, bare 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).
Needed if: you want to encrypt the message for many different people, including strangers, and they should be able to accept the message asynchronously, as in an e-mail, and then decrypt it offline. This is a rather specific use case.
Of all the cryptographic "correct answers", this one is unlikely to get on your own. Do not use freelance public key encryption and low-level cryptographic libraries like OpenSSL or BouncyCastle.
Here are some reasons why you should stop using RSA and switch to elliptic curves:
- RSA (and DH) pull you to "backward compatibility" with insecure systems, making protocol lower attacks possible.
- RSA asks to encrypt directly using its public key primitive, which usually contradicts the interests of users.
- RSA has too many settings. In modern systems on elliptic curves like Curve25519, everything is pre-configured for security.
NaCl uses the Curve25519 (the most popular modern system on elliptic curves, 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, your own library implementation) - use them. Do not try to collect everything yourself.
Do not use RSA.
Avoid: systems developed after 2015 using RSA, RSA-PKCS1v15, RSA, ElGamal, I do not know, Merkl - Hellman backpacks? 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.
Needed 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 authenticate a series of files coming at random times using the same secret key. Or you create a transport for encrypted messages.
The statements from the previous answer are fully applicable to this item.
Over the past 10 years, the two most important cases of using asymmetric signatures are cryptocurrency and the key agreement protocols of perfect forward secrecy, as in ECDHE-TLS. The dominant algorithms for these cases are based on elliptic curves. Be wary of new systems using RSA signatures.
In the past few years, there has been a significant transition from conventional DSA signatures to resistant against the abuse of “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 the reuse of a random number produced secret keys. Prefer deterministic signatures to any other signature schemes.
Ed25519 from the default NaCl / libsodium settings is now the most popular public key signature scheme outside of Bitcoin. It is resistant to abuse and carefully designed elsewhere. She too should not be self-designed; Take the implementation from NaCl.
Avoid: RSA-PKCS1v15, RSA, ECDSA, DSA; indeed, especially DSA and ECDSA should be avoided.
Diffie - Hellman
Percival, 2009: Work on the 2048-bit group # 14 with generator 2.
Ptacek, 2015: probably still DH-2048 or NaCl.
Latacora, 2018: probably nothing. Or use Curve25519.
This is necessary if: you are developing an encrypted transport or messaging system that strangers will ever use, and therefore AES static keys are not appropriate.
The 2015 version of this document has confused everyone to hell.
Part of the problem is that our "correct answers" is the answer to Colin Percival's "correct answers," and he included the answer about Diffie-Hellman, as if this is a common protocol for developers. In fact, developers simply do not have to freelance to create their own encrypted transports. To get an idea of ​​the complexity of this issue, read the Noise Protocol Framework documentation. If you are performing DH key exchange, you probably want to generate Shared Authentication Keys (AKE) that counter attacks with key compromise by disguising as a legitimate user (key compromise impersonation, KCI). So the primitive for DH is not the only serious security issue.
But never mind.
Everything remains the same: if you can just use NaCl, use NaCl. You don’t even have to worry 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 the implementations of the Javascript bignum. But in reality, the essence of Curve25519 partly lies in the fact that the entire curve is carefully selected to minimize implementation errors. Do not write your own! In fact, just use Curve25519.
Do not embed ECDH with NIST curves, where you will have to carefully check the elliptic curve points before using them for calculations to avoid secrets leaking. This attack is very simple to implement: easier than the padding oracle on the CBC, and much more destructive.
The 2015 document contained a clause about DH-1024 preferences 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 with the choice of “Use Blowfish or IDEA”. This choice should not be. Use Curve25519.
Avoid: normal DH, SRP, J-PAKE, handshakes and coordination, complex key agreement schemes using only block ciphers,
srand(time()).* .Website security
Percival, 2009: use OpenSSL.
Ptacek, 2015: OpenSSL or BoringSSL remains, 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 website.
If you can pay AWS to not care about this problem, then we recommend to do it.
Otherwise, there was a dark period between 2010 and 2016, when OpenSSL might not have been the right answer, but that time had passed. OpenSSL is better, and, more importantly, OpenSSL is ready to report and respond to vulnerabilities found.
Using something other than OpenSSL means making your system very difficult for a small, zero, or even negative security benefit. So be simple.
Speaking of simple: LetsEncrypt is a free and automated service. Set up a cron job for regularly collecting certificates and testing.
Avoid: Unusual TLS PolarSSL, GnuTLS and MatrixSSL libraries.
Client server security
Percival, 2009: Distribute the server's public RSA key with the 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.
Needed in case: the previous recommendations on public-key cryptography were relevant to you.
It seems a little crazy to recommend TLS, given the latest story:
- Logjam DH attack on session keys
- FREAK Attack on RSA_EXPORT
- Attack POODLE on CBC with oracle
- Fiasco RC4
- CRIME attack on compression algorithm
- Time attack Lucky13 type padding oracle on CBC ciphers
- BEAST attack on CBC cipher initialization vector
- Heartbleed
- TLS renegotiation
- 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. It is even possible not to use certificate authorities at all (although it is easy to install your own); you can simply use the whitelist of self-signed certificates — something like 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 TLS attacks. The reason that everyone does not do this is the need for backward compatibility, but it is not needed in its own protocol.
- Many of the listed attacks only work against browsers, because the victim must accept and execute Javascript controlled by the attacker in order to generate repetitive known / matched texts.
Avoid: Design your own transport encryption protocol, which is a truly complex engineering problem; use TLS in the default configuration (for example, with
curl ); use curl , ipsec.Online backups
Percival, 2009: use Tarsnap.
Ptacek, 2015: Use Tarsnap.
Latacora, 2018: store the PMAC-SIV encrypted arc files in S3 and save fingerprint backups 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 to sports”!
GlobalSign joins the celebration of the most ambitious event of all athletes and football fans - WORLD FOOTBALL CHAMPIONSHIP 2018 and GIVEN 1 YEAR SSL PROTECTION! *
Terms of action:
* When you purchase any one - year DV-OV or EV -level SSL certificate , you get the second year as a gift.
• The promotion applies to all sites of sports.
• 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 promotion from GlobalSign Russia managers by phone: +7 (499) 678 2210.
MORE PROTECTION with GlobalSign!
Source: https://habr.com/ru/post/353576/
All Articles