mirror of
https://code.briarproject.org/briar/briar.git
synced 2026-03-02 03:28:18 +01:00
akwizgran created page: BQP
38
BQP.markdown
Normal file
38
BQP.markdown
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
BQP is a key agreement protocol that establishes an ephemeral secure channel between a pair of mobile devices equipped with screens and cameras.
|
||||||
|
|
||||||
|
Each device displays a QR code containing a commitment to an ephemeral public key and information about how to connect to the device over various short-range transports. The devices scan each other's codes and use the connection information to establish an insecure duplex channel. The devices exchange public keys matching their commitments over the insecure channel. Each device derives the shared secret from its own private key and the received public key, and keys derived from the shared secret are used to secure the channel. Further information, such as long-term public keys, may then be exchanged over the secure channel.
|
||||||
|
|
||||||
|
The initial exchange of QR codes is assumed to be secure against man-in-the-middle attacks because the users can see which devices they are scanning. Man-in-the-middle attacks against the subsequent exchange of public keys over the insecure channel can be detected by comparing the keys to the commitments contained in the QR codes. We assume the adversary can read, modify, delete and insert traffic on the short-range transports at will.
|
||||||
|
|
||||||
|
### Notation
|
||||||
|
|
||||||
|
We use || to denote concatenation, double quotes to denote an ASCII string, and len(x) to denote the length of x in bytes, represented as a 32-bit integer. All integers in BQP are big-endian.
|
||||||
|
|
||||||
|
### Crypto primitives
|
||||||
|
|
||||||
|
BQP uses the following cryptographic primitives:
|
||||||
|
|
||||||
|
* A cryptographic hash function, H(m)
|
||||||
|
* A key agreement function, DH(pri, pub), where pri is one party's private key and pub is the other party's public key
|
||||||
|
* A message authentication code, MAC(k, m)
|
||||||
|
* An authenticated cipher, ENC(k, n, m) and DEC(k, n, m), where n is a nonce
|
||||||
|
|
||||||
|
All hashes are HASH_LEN bytes, all symmetric keys are KEY_LEN bytes and all nonces are NONCE_LEN bytes. The output of MAC(k, m) is MAC_LEN bytes, and the output of ENC(k, n, m) is AUTH_LEN bytes longer than m. For simplicity we require that MAC_LEN == KEY_LEN.
|
||||||
|
|
||||||
|
> Implementation note: We propose to use BLAKE2s as the hash function, Curve25519 as the key agreement function, keyed BLAKE2s as the message authentication code, and XSalsa20/Poly1305 as the authenticated cipher. This gives HASH_LEN = 32, KEY_LEN = 32, MAC_LEN = 32, NONCE_LEN = 24, and AUTH_LEN = 16.
|
||||||
|
|
||||||
|
### Key generation
|
||||||
|
|
||||||
|
Each device starts by generating a fresh ephemeral key pair (pri, pub). The commitment to the public key is H(pub).
|
||||||
|
|
||||||
|
### QR codes
|
||||||
|
|
||||||
|
Each device creates a QR code containing a binary payload. The payload is encoded using Base32, as defined in [RFC 4648](https://tools.ietf.org/html/rfc4648), which allows the QR code to use alphanumeric mode. The first byte of the payload is the protocol version, which is 1 for the current version of BQP. The next HASH_LEN bytes of the payload are the commitment to the ephemeral public key. The remainder of the payload consists of zero or more byte strings containing information about how to connect to the device over various short-range transports. Each byte string may be 0 to 255 bytes long, and is preceded by a single byte giving its length. The order of the transports is defined by BQP. The following transports are defined for version 1 of BQP:
|
||||||
|
|
||||||
|
1. Bluetooth. The byte string contains the device's Bluetooth MAC address (6 bytes). The UUID of the Bluetooth service is generated by converting the first 16 bytes of the public key commitment into a UUID as specified in section 4.4 of [RFC 4122](https://tools.ietf.org/html/rfc4122).
|
||||||
|
|
||||||
|
2. IP. The byte string contains the device's link-local or site-local IPv4 or IPv6 address (4 or 16 bytes), followed by a port number as a 16-bit integer (2 bytes).
|
||||||
|
|
||||||
|
3. Wi-Fi. The byte string contains the SSID and password for a Wi-Fi access point, which may be a Wi-Fi Direct legacy mode access point. The SSID and password are separated by a null byte.
|
||||||
|
|
||||||
|
This list of transports may be extended in future without incrementing the protocol version; devices must ignore any transports they do not recognise.
|
||||||
Reference in New Issue
Block a user