Add v1 message wrapper

[cammellos]

Adds the message wrapper from https://github.com/status-im/status-protocol-go/pull/19

I have also restructured x8 as Message is only one type of messages exchanged by the app, theres more that needs describing:PairInstallation,SyncInstallation,ContactRequest,ContactUpdate` and a few more.

[adambabik]

Oh, can we add these not-yet-described messages into the spec as well with TODO annotations? Alternatively, we can create an issue.

[oskarth]

@cammellos how does validation of signature work? Also did you consider using a MAC?

[cammellos]

@oskarth https://github.com/ethereum/go-ethereum/blob/d1aa605f1e8639769cdd75bcec3064c29a62b34a/crypto/secp256k1/secp256.go#L93 is the standard secp256 recovery from a signature and a signed payload.

Also did you consider using a MAC?

We can't use macs, it only works if there's a shared secret, and this should apply for public messages as well, where we don't know how the recipient is.

1-to-1 messages can optionally be non-signed, as discussed in the discuss post. In that case we could use the MAC from the double ratchet, and those messages will be pd and can't be relayed.

[oskarth]

Another thing: it might be useful to state more explicitly why we are introducing a signature, and what security goals this provides. As an example (https://crypto.stackexchange.com/questions/5646/what-are-the-differences-between-a-digital-signature-a-mac-and-a-hash), something like:

• integrity/authentication/non-repudiation
• which kind of keys it works for (vs e.g. Whisper underlying layer supporting both types)

As well a sentence or so on verification and requirements for it (keeping payload around)

What do you think?

[cammellos]

makes sense, i will add that

On Wed, Jul 17, 2019, 12:54 Oskar Thorén notifications@github.com wrote:

Another thing: it might be useful to state more explicitly why we are introducing a signature, and what security goals this provides. As an example, something like:

• integrity/authentication/non-repudiation
• which kind of keys it works for (vs e.g. Whisper underlying layer supporting both types)

As well a sentence or so on verification and requirements for it (keeping payload around)

What do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/status-im/specs/pull/34?email_source=notifications&email_token=AAHYJMH2INSXOS7WVSU4LTTP7325TA5CNFSM4IEM7Q22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2D2CLQ#issuecomment-512205102, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHYJMEXTYXU7IU6ZS7AF6LP7325TANCNFSM4IEM7Q2Q .

[oskarth]

Another thing: it might be useful to state more explicitly why we are introducing a signature, and what security goals this provides. As an example (https://crypto.stackexchange.com/questions/5646/what-are-the-differences-between-a-digital-signature-a-mac-and-a-hash), something like:

integrity/authentication/non-repudiation
which kind of keys it works for (vs e.g. Whisper underlying layer supporting both types)

As well a sentence or so on verification and requirements for it (keeping payload around)

What do you think?

makes sense, i will add that

If we do this I'd be happy with this, @decanus?

[cammellos]

@oskarth done, merging