Kaladaran/briar
0
0
Fork 0
mirror of https://code.briarproject.org/briar/briar.git synced 2026-03-05 04:58:18 +01:00
Code Issues Projects Releases Wiki Activity

akwizgran created page: BSP

akwizgran
2015-04-01 10:22:17 +00:00
parent 13f79076d0
commit d7dff95baf
1 changed files with 7 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
BSP.markdown

@@ -4,17 +4,21 @@ BSP synchronises data between two devices referred to as the local and remote pe
Each channel on the local peer belongs to an application. The application decides which messages stored on the local peer should be synchronised to the remote peer (the sharing policy), and which messages synchronised from the remote peer should be stored on the local peer (the storage policy). Each channel on the local peer belongs to an application. The application decides which messages stored on the local peer should be synchronised to the remote peer (the sharing policy), and which messages synchronised from the remote peer should be stored on the local peer (the storage policy).
### Notation
We use || to denote concatenation, double quotes to denote an ASCII string, int(x) to denote x represented as a 64-bit integer, and len(x) to denote the length of x in bytes, represented as a 32-bit integer. All integers in BSP are big-endian.
### Crypto primitives ### Crypto primitives
BSP uses a cryptographic hash function, H(m), with an output length of hash_len bytes. BSP uses a cryptographic hash function, H(m), with an output length of HASH_LEN bytes.
### Channel identifiers ### Channel identifiers
Each channel has a unique identifier hash_len bytes long. This identifier is supplied by the application and is not interpreted by BSP. To prevent collisions, the identifier must either be random, or be the cryptographic hash of an application data structure describing the channel. If a hash is used, a random application identifier hash_len bytes long must be prepended to the application data structure before hashing to prevent collisions between applications with similar data structures. Each channel has a unique identifier HASH_LEN bytes long. This identifier is supplied by the application and is not interpreted by BSP. To prevent collisions, the identifier must either be random, or be the cryptographic hash of an application data structure describing the channel. If a hash is used, a random application identifier HASH_LEN bytes long must be prepended to the application data structure before hashing to prevent collisions between applications with similar data structures.
### Message format ### Message format
Each message consists of one or more blocks. Each block is block_len bytes long, except the last block of the message, which may be shorter. (We require that block_len is not more than 2^15.) The blocks form the leaves of a binary hash tree. Each parent node consists of the concatenated hashes of its children. If the number of blocks in the message is not a power of two, some parent nodes will only have one child. Each message consists of one or more blocks. Each block is BLOCK_LEN bytes long, except the last block of the message, which may be shorter. (We require that BLOCK_LEN <= 2^15 .) The blocks form the leaves of a binary hash tree. Each parent node consists of the concatenated hashes of its children. If the number of blocks in the message is not a power of two, some parent nodes will only have one child.
The message's unique identifier is calculated by hashing a message header concatenated with the root hash of the tree. The message header consists of the channel identifier, a timestamp, the message length and the message type. The message's unique identifier is calculated by hashing a message header concatenated with the root hash of the tree. The message header consists of the channel identifier, a timestamp, the message length and the message type.