Comments (19)
I think 1216 comes from the sizes:
R0 = 448 bits
H0 = 256 bits
Ca0_0 || Cb0_0 = 256 bits each = 512
448 + 256 + 512 = 1216
from otrv4.
- SymmetricEnc: AES-256 256-bit (128-bit on PQ)
- hash: sha256 256-bit
- Group: ed25519 126-bit (128-bit as the paper state)
- Group: ed448 223-bit conjectured security level
from otrv4.
I don't understand what the comment means.
from otrv4.
I thought it was to figer out the bit level, that del came from the decision of dake, we don't need AEnc if no DRE used, so what does your "security level question" mean?
from otrv4.
The security level is for the whole protocol, not just the AKE. And OTR will still need to use AES for encryption. Don't just focus on the AKE, OTR is much more than that.
from otrv4.
Also, AES-256 has 256 bits of security level in terms of key size. It has only 128-bits of block size, but I'm unsure if that changes the security level or not.
On the other hand, if we are doing PQ security level, the security level of AES-256 is 128.
Basically, I think that comment had a bunch of weird stuff in it, and I still don't understand what it means.
from otrv4.
Yes you're right, aes256 should be 256-bit in that case, what else do you think we may use?
from otrv4.
??
from otrv4.
I'm lost, by saying " I think that comment had a bunch of weird stuff in it", what do you mean?
from otrv4.
I don't understand what the comment is trying to say. It is trying to enumerate the alternatives we have? Or what is the point of it?
from otrv4.
Problem: we need to evaluate the security level of the protocol, including AKE and encrypted data messages.
To figure this out, we´re going to look at the cryptographic primitives in:
- The DAKE
- Data Message exchange
from otrv4.
DECISION 1: ed25519 vs ed448
Curve25519 has ~128-bit security level and Curve448 has ~224-bit security level [3]
ed25519
This system has a 2^128 security target; breaking it has similar difficulty to breaking NIST P-256, RSA with ~3000-bit keys, strong 128-bit block ciphers, etc. The best attacks known actually cost more than 2^140 bit operations on average, and degrade quadratically in success probability as the number of bit operations drops. [1]
The curve is a 255-bit Edwards curve.
ed448
This is a 448-bit Edwards curve with a 223-bit conjectured security level. [...] For practical security concerns, you should use the faster and more mature Curve25519 / Ed25519 software, or similar. [2]
1 - https://ed25519.cr.yp.to/
2 - https://sourceforge.net/p/ed448goldilocks/wiki/Home/
3 - https://tools.ietf.org/html/draft-irtf-cfrg-curves-11
from otrv4.
We are not sure about the expected output of this issue. Is it any of:
a. Coming up with a single number of bits that represent the security level of the whole protocol?
b. Making a decision about the cryptographic primitives to use on the whole protocol based on the security level of each primitive?
For (a) we could not find a methodology for reducing the security level of the different crypto primitives used in a protocol to a single number. In addition to that none of the papers[1] we looked at mention the security level of, for example, OTR or TextSecure as a protocol.
For (b) there's something we can do.
1 - We looked at OTR introductory paper, "How secure is TextSecure" and "SoK: Secure Messaging".
from otrv4.
???? You need to do both things, of course. Refer to Cryptography Engineering.
The security level of the whole protocol will roughly be the lowest security level of the primitives used - which ones we should aim for the same security level of all primitives, more or less.
from otrv4.
Our goal then is to evaluate all primitives used in the AKE, ratcheting and data message exchange and choose primitives with roughly the same security level.
AKE
For SPAWN we need:
Cramer-Shoup
"The proof of security for the scheme assumes only the hardness of the decisional Diffie-Hellman problem in the underlying group, and the collision resistance of the underlying hash function." ([1], page 122)
Assuming the security level depends on the same primitives, the options are:
- Curve 25519 (128-bit) or Curve 448 (224-bit).
- SHA3-256 (128-bit) or SHA3-512 (256-bit). [3]
Ephemeral D-H key pair
We need to choose a group G to generate (i, g1^i)
and (r, g1^r)
. The options are:
- Curve 25519 (128-bit) or Curve 448 (224-bit). It must be the same group used for the Cramer-Shoup.
ROM Dual-Receiver Encryption (DRE)
In [1] DRE's has a security parameter λ "provided to control the security level of the system". This value controls the length of r
. In [2] ROM DRE uses the following primitives:
- A collision-resistant hash function
H1
- A cryptographic hash function modeled by a random oracle,
H2
- Cramer-Shoup scheme
We believe the security level will be defined by λ, H1, H2 and the Cramer-Shoup scheme. The options are:
- The same for the Cramer-Shoup scheme defined earlier.
- For H1 and H2 (they all need to output values in
Zq
):- SHA3-256 (128-bit) or SHA3-512 (256-bit). [3]
- We need to decide
λ
so thatr
has enough bits to generate:r = x1 || x2 || y1 || y2 || z
r = K || k1 || k2
DRE also uses AEnck
: "an encryption under key K using an implementation-defined cryptosystem with IND-CCA2 security."[2] The options are:
- AES-192 or AES-256 in OCB (recommended by [2]).
The size of K
must be chosen as long as necessary to be used as key in AEnck
(192-bits for AES-192, 256-bits for AES-256).
ROM Authentication
A_i = g ^ a_i
is on a group G.- a hash function
H
modeled by a random oracle.
The options are:
- For the group: Curve 25519 (128-bit) or Curve 448 (224-bit).
- For H: SHA3-256 (128-bit) or SHA3-512 (256-bit). [3]
The shared secret k
The shared secret k
has the size of a group element from G. This is the input for the ratcheting so we need to make sure the choice of the group generates k
with an appropriate size.
1 - Deniable Key Exchanges for Secure Messaging
2 - Improved Techniques for Implementing Strongly Deniable Authenticated Key Exchanges
3 - https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions
from otrv4.
Ratcheting and sending encrypted messages
Derive root, header and chain keys
How many bits we need to generate from the shared secret k
? We need to generate:
- root key (Ri): is used as shared secret the next time we begin a new ratchet. Does it need to have the same size of
k
? - header key (Hi): is used to encrypt the header.
- chain key (Ci_j): is used as input to SHA3-256 to generate message keys (MKenc, Mkmac).
We must use a Key Derivation Function (KDF) for this because we want to generate cryptographically strong key from a D-H shared secret. The options are:
- HKDF[1]. But it uses HMAC and we have replaced the existing HMAC with SHA3. Is this a problem?
- The same strategy as OTRv3 to generate additional keys from the shared secret. [2]
Generate D-H key pair on a new ratchet
Options are:
- Curve 25519 (128-bit) or Curve 448 (224-bit).
Encrypt the header
The header contains (msgNum, pubDHRs) and is symmetrically encrypted with Enc
using header key (Hi). The options are:
- AES-256 counter-mode (CTR)?
Encrypt and MAC the message
MKenc and MKmac are derived from Ci_j. Do we need a KDF for this or is it enough to use a hash function? The KDF will define the size of MKenc and MKmac.
Symmetrically encrypt message with Enc
using MKenc
key. Options are:
- AES-256 counter-mode (CTR)?
MAC the encrypted data with MAC
using MKmac
key. Options are:
- SHA-3(key || message).[3]
Derive Ci_j+1
. Do we need a KDF for this or is it enough to use a hash function?
1 - https://tools.ietf.org/html/rfc5869
2 - See "Off-the-Record Messaging Protocol version 3", section "Computing AES keys, MAC keys, and the secure session id".
3 - http://keccak.noekeon.org
from otrv4.
Target: 224-bit security
- D-H Group: curve 448 (224-bit security)
- Hash function: SHA3-512 (256-bit security).
- Cramer-Shoup: will use generator from the same curve 448.
DRE (considering key generation, encryption and decryption):
- H1 and H2: SHA3-512
- For key generation:
- x1, x2, y1, y2, z are numbers in Zq (446 bits). λ is 5 * 446.
- For encryption / decryption:
- K, k1, k2 are numbers in Zq. λ is 3 * 446.
- AEnck: AES-256 in OCB (recommended by the paper). K is 446 bits long. AES-256 requires a 256-bit key.
- AES has 128-bit block size, and the security level is 128-bits. Does it mean AES block size is the limit for the security level in this protocol, regardless of other choices?
- The NIZKPK uses two hashes, they could both be SHA3-512 to output values in Zq (446-bits).
Auth
- D-H Group: curve 448.
- Hash function: SHA3-512.
Shared secret (k)
has size 446-bits (56 bytes) - from ed448 implementation (and X448).
Deriving root, header and chain keys:
R0 || H0 || Ca0_0 || Cb0_0 = SHAKE256(1216, k)
- H0 may be unnecessary if we don't encrypt the header.
- First KDF is not keyed, unlike the subsequent KDFs.
- Security level of the output is 256-bit. But because the output is split into several pieces, how does it impacts the security of individual pieces? OTRv3 uses a similar approach to generate c and c' while keeping 128-bit security: it generates a 256 bits output (with 128-bit security) and split into two 128 bits output (with 128-bit security).
- How is this different from having an approach similar to OTRv3?
- R0 = first 448 bits of SHA3-512(0x01 || k)
- H0 = first 256 bits of SHA3-512(0x02 || k)
- Ca0_0 || Cb0_0 = SHA3-512(0x03 || k)
- It's easy to understand the security level of the previous approach when comparing to having a single SHAKE256.
The sizes can be:
- R0: 448 bits (56 bytes), if it needs to have the same size of the shared secret.
- H0: 256 bits (32 bytes) long. It will be used as key to AES-256 in to encrypt the header.
- Ca0_0 and Cb0_0: 256 bits (32 bytes) long each.
On a new ratchet
- pubDHRs, privDHRs: D-H using curve 448.
k2 = ECDH(privDHRs, pubDHRr)
Ri, Hi, Cai_0, Cbi_0 = SHAKE256(1216, Ri-1 || k2)
- SHAKE input is 896 bits long: k2 and Ri are both 56 bytes long.
- The security level of SHAKE256 is 256-bit.
- Length of
Ri, Hi, C[a,b]i_j
should be the same as initially generated values.
Encrypting the header
header = AES-256(Hi, Ns || Nr || pubDHRs)
Enc
: AES-256 but which mode? Do we really need to encrypt the header?
Encrypt and MAC the message
Mkenc || Mkmac = SHA3-512(Ci_j || "0")
- Both MKenc and Mkmac will be 256 bits long. Security level is 256-bit.
ciphertext = AES-256(Mkenc, plaintext)
mactag = SHA3-512(Mkmac || ciphertext)
Enc
is AES-256 CTR, so Mkenc needs to be 256 bits long (32 bytes).- The IV in OTRv3 is 16-bytes (big endian): first 8 are similar to
Ns
and last 8 are zeroes. We could use a similar approach, but in the double ratchet context each message is encrypted with a different key and I wonder if this is still necessary.
- The IV in OTRv3 is 16-bytes (big endian): first 8 are similar to
MAC
has 256-bits of security.
j = j + 1
Cai_j || Cbi_j = SHA3-512(Cai_j-1 || Cbi_j-1 || j)
- Is this correct?
TODO
- Understand how to choose the KDF and choose one.
- Present another plan for targeting 128-bit security level (using curve 25519).
- Share and discuss with the group.
- Clarify about AES block size being the lower bound for the security level.
- Explore using Chacha20 as block cipher or Salsa20 as stream cipher (both provides 256-bit security) See: https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-06#section-4 and https://cr.yp.to/snuffle/salsafamily-20071225.pdf
from otrv4.
Ok, if we don't use Header key, would it be very different for KDF?
Where is 1216 come from?
from otrv4.
from otrv4.
Related Issues (20)
- Check that we are advising to queue messages in the correct places
- Recover rights of github.com/off-the-record and update HOT 6
- Where to find Double Ratchet implementation in libotr-ng HOT 2
- Issue in `ECDH(a, B)` with check calculating shared secret? HOT 1
- When should we delete skipped_MKenc? HOT 1
- Create a contributing document
- Migrate to gitlab HOT 5
- Create a CONTRIBUTING page
- Synchronize with gitlab instance HOT 12
- Key Registration with Knowledge HOT 1
- Create a plan for 2020 in relationship with the new outcomes as defined in some meetings HOT 2
- Conversations Legacy has been removed HOT 4
- Update for Psi and Psi+ in Wiki page HOT 5
- Clarify what it means to "Send new Auth-R message with new values"
- Add an extension TLV to upgrade to v4 HOT 11
- Application/protocol-specific TLVs
- [Idea] PSK-authenticated fingerprint verification
- http://bugs.otr.im/otrv4/otrv4 is down. HOT 3
- Status of the OTRv4 specification HOT 1
- Concerns regarding verification of generated shared secret (identity checking)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from otrv4.