| … | |
… | |
| 142 | |
142 | |
| 143 | RAND is a sequence of fully random bytes, used to increase the entropy of |
143 | RAND is a sequence of fully random bytes, used to increase the entropy of |
| 144 | the data for encryption purposes. |
144 | the data for encryption purposes. |
| 145 | |
145 | |
| 146 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
146 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
| 147 | initialization and starts at some random 31 bit value. VPE currently uses |
147 | initialization and starts at some random 31 bit value. GVPE currently uses |
| 148 | a sliding window of 512 packets/sequence numbers to detect reordering, |
148 | a sliding window of 512 packets/sequence numbers to detect reordering, |
| 149 | duplication and replay attacks. |
149 | duplication and replay attacks. |
| 150 | |
150 | |
| 151 | The encryption is done on RAND+SEQNO+DATA in CBC mode with zero IV (or, |
151 | The encryption is done on RAND+SEQNO+DATA in CBC mode with zero IV (or, |
| 152 | equivalently, the IV is RAND+SEQNO, encrypted with the block cipher, |
152 | equivalently, the IV is RAND+SEQNO, encrypted with the block cipher, |
| 153 | unless RAND size is decreased or increased over the default value). |
153 | unless RAND size is decreased or increased over the default value). |
|
|
154 | |
|
|
155 | The random prefix itself is generated by using AES in CTR mode with a |
|
|
156 | random key and starting value, which should make them unpredictable even |
|
|
157 | before encrypting them again. The sequence number additionally ensures |
|
|
158 | that the IV is unique. |
| 154 | |
159 | |
| 155 | =head2 The authentication/key exchange protocol |
160 | =head2 The authentication/key exchange protocol |
| 156 | |
161 | |
| 157 | Before nodes can exchange packets, they need to establish authenticity of |
162 | Before nodes can exchange packets, they need to establish authenticity of |
| 158 | the other side and a key. Every node has a private RSA key and the public |
163 | the other side and a key. Every node has a private RSA key and the public |
| … | |
… | |
| 203 | of the original challenge. |
208 | of the original challenge. |
| 204 | |
209 | |
| 205 | The result of this process is to authenticate each node to the other |
210 | The result of this process is to authenticate each node to the other |
| 206 | node, while exchanging keys using both RSA and ECDH, the latter providing |
211 | node, while exchanging keys using both RSA and ECDH, the latter providing |
| 207 | perfect forward secrecy. |
212 | perfect forward secrecy. |
|
|
213 | |
|
|
214 | The protocol has been overdesigned where this was possible without |
|
|
215 | increasing implementation complexity, in an attempt to protect against |
|
|
216 | implementation or protocol failures. For example, if the ECDH challenge |
|
|
217 | was found to be flawed, perfect forward secrecy would be lost, but |
|
|
218 | the data would still be protected. Likewise, standard algorithms and |
|
|
219 | implementations are used where possible. |
| 208 | |
220 | |
| 209 | =head2 Retrying |
221 | =head2 Retrying |
| 210 | |
222 | |
| 211 | When there is no response to an auth request, the node will send auth |
223 | When there is no response to an auth request, the node will send auth |
| 212 | requests in bursts with an exponential back-off. After some time it will |
224 | requests in bursts with an exponential back-off. After some time it will |
