search

ROBERT-proximity-tracing / documents

Protocol specification, white paper, high level documents, etc.
Other
247 stars 21 forks source link

Do not use 3DES as a potential block-cipher #3

Open mlpo opened 4 years ago

mlpo commented 4 years ago

In Section 4, the EBID (Ephemeral Bluetooth Identifier for A) is generated using a 64-bit block-cipher where 3DES is given as a potential solution.

3DES is today considered as a weak cipher, and should not be promoted in modern solutions. Several sources (Wikipedia article cites a number of them) report this scientific consensus and show various weaknesses of this cipher.

Instead, more secure solutions should be considered.

bortzmeyer commented 4 years ago

Is it really a problem? I know that 3DES is unsafe for general-purpose encryption but here, it is just to generate pseudo-random identifiers.

mlpo commented 4 years ago

Well, as it stands, I agree that the use of 3DES does not seem to be an immediate critical problem (not practically exploitable). Moreover, broadly speaking, the real risk engendered by the choice of this primitive is low (3DES is relatively safe to use for 112-bit security for general-purpose applications).

Here, it is used to generate an ephemeral pseudo-random identifier, and the main liability of this cryptographic operation is to prevent a malicious user from obtaining the permanent identifier for A (breach of privacy). Assuming 3DES would be used with keying option 1 (3-key), main weaknesses of 3DES (Meet-in-the-Middle attacks and variants) would require chosen-plaintext or known-plaintext conditions to be applicable, which actually does not happen in this protocol.

But I think the issue raised stands: as I understand it, the point here is to propose a new protocol, and the cryptographic routines used does not seem to be prescribed here by compelling reasons (e.g. interoperability or backward compatibility). Therefore, we might as well choose modern, high-performance and secure alternatives (particularly with regard to the quantity of analyses and attacks—theoretical and practical—available in the scientific literature). 3DES is evoked as a potential solution, we might as well propose a “better one”.

The cost-benefit analysis here seems to me to be quite favourable to this, although it is certainly not a critical problem.

Gu1nness commented 4 years ago

It seems to me completely unrealistic to use 3DES whereas some other protocols can easily replace it and are considered as secure by the community such as AES. In my opinion, this show the loss of sense of reality of the authors of this document.

PRIVATICS-Inria commented 4 years ago

Thanks @mlpo for your comment.

As pointed in our document, a block-cipher of 64-bit block size is needed (the size limitation comes from the constraints Bluetooth impose on the message size). TripleDES was just presented as a possible option. We acknowledge that it has weakness and that other options may exist. As you pointed out, lightweight block-ciphers are available (https://www.cryptolux.org/index.php/Lightweight_Block_Ciphers) but as far as we know, there is no clear consensus on them. We will revise our document to clarify this point.