Commit 46809d7b790e03772019f4405fe587a12b885f57
document double signatures & hmac key
Dominic Tarr committed on 2/7/2019, 3:52:15 PMParent: 0e94992aa8bedac43906183f616bff699ec2484b
Files changed
| README.md | changed |
| README.md | ||
|---|---|---|
| @@ -233,20 +233,52 @@ | ||
| 233 | 233 … | with what alice says about him) |
| 234 | 234 … | |
| 235 | 235 … | ## messages |
| 236 | 236 … | |
| 237 … | +because the trick here is two keys are associated, | |
| 238 … | +some particular techniques are used. | |
| 239 … | + | |
| 240 … | +#### double signatures | |
| 241 … | + | |
| 242 … | +notice a pattern with two keys and two signatures, | |
| 243 … | +the inner, short term key, signs the outer long term public key, | |
| 244 … | +and then the outer, long term key, signs the signed message | |
| 245 … | +of the short term key. | |
| 246 … | + | |
| 247 … | +``` | |
| 248 … | +sign(sign({message, long_term.public}, short_term), long_term) | |
| 249 … | +``` | |
| 250 … | + | |
| 251 … | +A key point here is that the inner signs the public key of the outer. | |
| 252 … | +Otherwise another party could just replay the inner portion, | |
| 253 … | +but by signing the long term key (and checking this when validating, | |
| 254 … | +this is prevented). | |
| 255 … | + | |
| 256 … | +#### signing capability | |
| 257 … | + | |
| 258 … | +the inner signatures uses [`ssbKeys.signObj(key, hmac_key?, obj)`](https://github.com/ssbc/ssb-keys#signobjkeys-hmac_key-obj) | |
| 259 … | +with an _`hmac_key`_ provided. The purpose of this is to ensure | |
| 260 … | +that this signature can never be confused with a signature used for | |
| 261 … | +other purposes (such as ordinary message signing). | |
| 262 … | + | |
| 237 | 263 … | ### peer-invite |
| 238 | 264 … | |
| 239 | 265 … | published by the host when creating the invite. |
| 240 | 266 … | |
| 241 | 267 … | ``` js |
| 242 | 268 … | { |
| 243 | - type: 'peer-invite', | |
| 244 | - host: author_id, // author of this message. | |
| 245 | - invite: guest_temp_id, // public key guest will use to authenticate | |
| 246 | - reveal: boxed, // encrypted message to be revealed (optional) | |
| 247 | - private: boxed, // encrypted message for guest only (optional) | |
| 248 | - signature: sig, //signed by `guest_temp_id`, to prove that `author` held that. | |
| 269 … | + previous: ..., | |
| 270 … | + author: host_longterm_id, | |
| 271 … | + ... //other required message fields | |
| 272 … | + content { | |
| 273 … | + type: 'peer-invite', | |
| 274 … | + host: author_id, // author of this message. | |
| 275 … | + invite: guest_temp_id, // public key guest will use to authenticate | |
| 276 … | + reveal: boxed, // encrypted message to be revealed (optional) | |
| 277 … | + private: boxed, // encrypted message for guest only (optional) | |
| 278 … | + signature: inner_sig, //signed by `guest_temp_id`, to prove that `author` held that. | |
| 279 … | + }, | |
| 280 … | + signature: sig //signed by author. | |
| 249 | 281 … | } |
| 250 | 282 … | ``` |
| 251 | 283 … | |
| 252 | 284 … | ### peer-invite/accept |
| @@ -254,18 +286,26 @@ | ||
| 254 | 286 … | published by guest when accepting the above invite. |
| 255 | 287 … | |
| 256 | 288 … | ``` js |
| 257 | 289 … | { |
| 258 | - type: 'peer-invite/accept', | |
| 259 | - receipt: invite_id, // the id of the invite message (which is being accepted). | |
| 260 | - id: guest_long_term_id, // the real identity which the guest will use now. | |
| 261 | - key: hash(seed), // key used to encrypt the `reveal` field. required if reveal was present. | |
| 262 | - // if the guest does not wish to reveal that info, they should ask | |
| 263 | - // their host to create another invite. | |
| 264 | - signature: sig // signed by guest_temp_id, to prove that guest_long_term_id held that. | |
| 290 … | + previous: ..., | |
| 291 … | + author: guest_long_term_id, | |
| 292 … | + ... //other required fields, | |
| 293 … | + content: { | |
| 294 … | + type: 'peer-invite/accept', | |
| 295 … | + receipt: invite_id, // the id of the invite message (which is being accepted). | |
| 296 … | + id: guest_long_term_id, // the real identity which the guest will use now. | |
| 297 … | + key: hash(seed), // key used to encrypt the `reveal` field. required if reveal was present. | |
| 298 … | + // if the guest does not wish to reveal that info, they should ask | |
| 299 … | + // their host to create another invite. | |
| 300 … | + signature: inner_sig // signed by guest_temp_id, to prove that guest_long_term_id held that. | |
| 301 … | + }, | |
| 302 … | + signature: outer_sig | |
| 265 | 303 … | } |
| 266 | 304 … | ``` |
| 267 | 305 … | |
| 306 … | +a double signature is used as with the `peer-invite` message. | |
| 307 … | + | |
| 268 | 308 … | ### peer-invite/confirm |
| 269 | 309 … | |
| 270 | 310 … | published by a pub, when observing an invite accept message. |
| 271 | 311 … | it just embeds the accept_message. |
| @@ -291,4 +331,16 @@ | ||
| 291 | 331 … | |
| 292 | 332 … | |
| 293 | 333 … | |
| 294 | 334 … | |
| 335 … | + | |
| 336 … | + | |
| 337 … | + | |
| 338 … | + | |
| 339 … | + | |
| 340 … | + | |
| 341 … | + | |
| 342 … | + | |
| 343 … | + | |
| 344 … | + | |
| 345 … | + | |
| 346 … | + | |
Built with git-ssb-web