Coder Social home page Coder Social logo

Comments (19)

claucece avatar claucece commented on June 1, 2024 1

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.

tcz001 avatar tcz001 commented on June 1, 2024
  • 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.

olabini avatar olabini commented on June 1, 2024

I don't understand what the comment means.

from otrv4.

tcz001 avatar tcz001 commented on June 1, 2024

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.

olabini avatar olabini commented on June 1, 2024

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.

olabini avatar olabini commented on June 1, 2024

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.

tcz001 avatar tcz001 commented on June 1, 2024

Yes you're right, aes256 should be 256-bit in that case, what else do you think we may use?

from otrv4.

olabini avatar olabini commented on June 1, 2024

??

from otrv4.

tcz001 avatar tcz001 commented on June 1, 2024

I'm lost, by saying " I think that comment had a bunch of weird stuff in it", what do you mean?

from otrv4.

olabini avatar olabini commented on June 1, 2024

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.

juniorz avatar juniorz commented on June 1, 2024

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.

juniorz avatar juniorz commented on June 1, 2024

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.

juniorz avatar juniorz commented on June 1, 2024

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.

olabini avatar olabini commented on June 1, 2024

???? 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.

juniorz avatar juniorz commented on June 1, 2024

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 that r 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.

juniorz avatar juniorz commented on June 1, 2024

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.

juniorz avatar juniorz commented on June 1, 2024

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.
  • 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

from otrv4.

tcz001 avatar tcz001 commented on June 1, 2024

Ok, if we don't use Header key, would it be very different for KDF?
Where is 1216 come from?

from otrv4.

juniorz avatar juniorz commented on June 1, 2024

from otrv4.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.