## 4 Methods
### Stellar
#### 4.3.1 Encryption  
Unlike permissioned blockchains like Fabric, Stellar allows anyone to join the network and replicate the whole blockchain. To achieve data privacy over a public ledger, we propose an encryption mechanism. Sensors' logs are encrypted using asymmetric encryption, meaning each sensor can encrypt only its logs and cannot decrypt any other's. On the other hand, the owner of the campaign (or some other authorized unit) can decrypt all logs. Theoretically, the encryption could be achieved using ElGamal public-key encryption. Each sensor would encrypt a memo field using a publicly known encryption key, while the decryption would be possible only with a corresponding private decryption key. Unfortunately, this scheme produces ciphertext two times larger than the key size. The ciphertext is stored in the memo field, which is bounded to 32 bytes, meaning that keys are bounded to 16 bytes, which are far from secure.  
Instead of carrying out public-key encryption, we can leverage the fact that the memo is encoded within the Stellar transaction. Therefore, each transaction is associated with the sender's and receiver's public keys. We can use Elliptic Curve Diffie-Hellman (ECDH) to derive the symmetric encryption key--unique for each sender--and use AES-256-CTR for symmetric encryption. In elliptic curve cryptography, the private key is a \(n\)-bit integer where \(n\) is the key size.  
Let us call the private key \(k\) and its corresponding public key represented by the point on the curve \(K\), where \(K=k*G\) and \(G\) is the known constant point on the curve. If we take two key-pairs, sensor \((k_{s},K_{s})\) and campaign \((k_{c},K_{c})\), then using ECDH, we can derive the _shared secret_ used to perform symmetric encryption via AES-CTR.  
The shared secret can be derived by both  
\[k_{v}*K_{b}\;\;\text{and}\;\;k_{b}*K_{v} \tag{1}\]  
The keys are equal because  
\[k_{v}*K_{b}=k_{v}*k_{b}*G=k_{b}*k_{v}*G=k_{b}*K_{v}. \tag{2}\]  
There is still one more issue we need to solve. The Stellar protocol uses an ed25519 digital signature scheme based on the Twisted Edwards curve. However, the protocol to achieve ECDH called X25519 uses the Montgomery curve. These curves are birationally equivalent, meaning that we can convert points from one curve to the other [51].  
The formula to convert edwards25519 keys to curve25519 keys is as follows:  
A private key is generated by taking the first 32 bytes of the hash of the seed, then preventing small-subgroup attacks [52] by clearing the three lowest bits and preventing timing attacks by setting the most significant bit (see Listing 1).  
```
x = H(seed)[:32] x[0] &= 0b1111100 x[31] &= 0b01111111 x[31] | = 0b0100000
```  
**Listing 1**Converting edwards25519 private key to corresponding curve25519 private key. H is an SHA-512 hash function, [:32] takes the first 32 bytes of the array, &= is a bitwise AND operator, and |= is a bitwise OR operator.  
The public key is calculated using the following formula:  
\[u=\frac{(1+y)}{(1-y)}\]where \(y\) is the \(y\)-coordinate of a point on [PERSON]'s twisted curve representing the public key, and \(u\) is the resulting public key \(u\)-coordinate on the Montgomery curve.