Bitjoe intro

Code

Bitjoe is implemented in two languages:

• Java: meant to work on the server side
• JavaScript: to work in a Chrome App and Node.js, both on the server and in node-webkit. It provides an optional RESTful API and a client JS api which issues RESTful requests for you.

Brief bitjoe algo description:

Goal:

1. encrypt and store file F in an untrusted DHT
2. enable an arbitrary number of parties to find and decrypt F
3. enable the addition of privy parties at any point in the future
4. enable validation that F's contents haven't changed

Sketches of two variants are presented.

Notes:

1. H as used below refers to a secure cryptographic hash function, assume SHA256 for now
2. Though the DHT can associate any key to any value, we always use key = H(value)
3. Read encrypt(A, K) as "encrypt A with key K"

1. With an intermediate file

   For Alice to share a file F (order/contract/will/etc.) with Bob:

   1. Alice encrypts F with symmetric key S, computes L = H(F_ciphertext), puts (L, F_ciphertext) into DHT
   2. Alice creates intermediate file I containing S and L encrypted with Alice and Bob's shared secret K: K = A * b = B * a. A and B are Alice and Bob's public keys, respectively.
   3. Alice computes E = encrypt(H(I), K), puts E in the blockchain and (H(I), I) into DHT.
   4. Bob takes E from the blockchain, decrypts with K to get H(I), locates I and decrypts contents (S and L) with K.
   5. Bob finds F_ciphertext at location L in the DHT, verifies that L = H(F_ciphertext) and decrypts with S.

   To give a new party Carol access, Bob can create a new file J analagous to I, but with shared key K = B * c = C * b.

   (May be vulnerable to timing attacks - if timing of placement of I and F into storage can be used to associate them together, it negates any location obfuscation benefits)

2. Without an intermediate file:

   For Alice to share a file F (order/contract/will/etc.) with any number of parties:

   Source: https://bitcointalk.org/index.php?topic=196378.msg2531456#msg2531456

   1. Alice generates unique EC key pair (S, s), derives symmetric key X from S.
   2. Alice encrypts F with X, computes L = H(F_ciphertext), stores the pair (L, F_ciphertext) in the DHT.
   3. Alice computes M = encrypt(L, X) and stores M in the blockchain.
   4. Alice distributes "clues" K₁, K₂,..., Kn to recipients with public keys R₁, R₂,..., Rn, where K₁ = R₁ * s, K₂ = R₂ * s, etc.
   5. Each recipient i derives S (and from S derives X) using his private key r_i and "clue" K_i: S = r_i^-1 * K_i.
   6. Recipients decrypt M with X, obtaining the location of F, then decrypt F with X.

   Giving a new party access works exactly the same way as giving access to the initial parties.

Both schemes can be bolstered with the anonymity techniques described in Timo Hanke and Ilja Gerhardt's paper Homomorphic Payment Addresses and the Pay-to-Contract Protocol to obfuscate the broadcast of the encrypted file hash on the blockchain and protect the anonymity of the parties sharing F.