-

Sat, 15 Jun 2019 16:46:18 +0200 последнее редактирование: Sat, 15 Jun 2019 16:59:07 +0200

kostikov@zotum.net

!zotlabs.org | Hubzilla Development

I have created merge request with personal message signature processing as preparation for fully functional #E2E #encryption in #Hubzilla.
https://framagit.org/hubzilla/core/merge_requests/1670
Because of I assume to use JSON for signatures representation it contains base64 encoding / decoding procedures on receiving and sending signature from and to client as workaround for double quotes usage conflict with template engine.

encryption Hubzilla E2E

show all 13 comments

Sat, 15 Jun 2019 16:54:51 +0200

Manuel JF

manuel-jf@hub.volse.no

IoI

Sat, 15 Jun 2019 23:11:34 +0200

Mario Vavti

mario@hub.somaton.com

I have merged this.

There has been some talk a while ago to deprecate the mail app in favor of a separate interface for direct messages. I do not remember the details right now. Might have had something to do in relation with zot6.

Sat, 15 Jun 2019 23:19:30 +0200

Max Kostikov

kostikov@zotum.net

@Mario Vavti

talk a while ago to deprecate the mail app

It seems I have missed this. Maybe now is a right time to return to this discussion until I didn't went too far... :-)

Sat, 15 Jun 2019 23:48:22 +0200

El Dorado

mike@z.macgirvin.com

Right now there is no mail app at all in Zap - and there is no mechanism in Zot6 to send mail differently from regular posts. We currently use private (@!) tags when we want to send a DM. I think some ActivityPub projects have agreed on using a litepub:directMessage flag within ActivityStreams to distinguish these from normal private posts, and Zap (which uses ActivityStreams but not ActivityPub) may or may not implement this.

Right now there is no need to remove the separate mail interface from Hubzilla - and as long as federation with Diaspora is a thing it may be impossible or impractical to do so. But in your planning you might think about representing these messages in ActivityStreams and ActivityPub. And if Diaspora isn't willing to add E2EE to their own mail interface (good luck getting them to do anything), you'll have to make sure that the mail interface still works with Diaspora recipients.

Sun, 16 Jun 2019 00:32:31 +0200

Max Kostikov

kostikov@zotum.net

@Mike Macgirvin
Thanks for clarification. As I understand at this moment we have not any recognized standard on Fediverse cryptography in common and personal / direct messages in particular. I found few related proposals on standards and now thinking if they should be took in account for planned E2EE in Hubzilla.

https://w3c-dvcg.github.io/ld-signatures/
http://files.de.adversary.org/crypto/ac/index.html

Sun, 16 Jun 2019 01:22:57 +0200

El Dorado

mike@z.macgirvin.com

I hadn't seen ac (pgp over AS) - that's definitely the direction I think we want to go.

Sun, 16 Jun 2019 21:44:59 +0200 последнее редактирование: Sun, 16 Jun 2019 22:42:15 +0200

Max Kostikov

kostikov@zotum.net

Todays thoughts.

Signatures representation for end-to-end encryption and signing
===============================================================


1. Basics
---------

1.1. Message can be signed or encrypted and signed.
1.2. If message should be signed and encrypted signining must be performed after encryption.
1.3. Signing or encryption and signing by default applies on message body only.
1.4. If both sigining and encryption appplies message should be encrypted first.
1.5. JSON objects representation used.


2. Signing
----------

2.1. Fields when signing

signatures        - Array of signatures.
algorithm        - MUST. String.
scope            - MAY. Array. If absent only body signed.
linked            - MAY. Boolean. If set signing key is available for fetch by URL.
signingKeyID    - MUST. String. Base64 encoded key or URL.
signature        - MUST. String. Base64 encoded signature.

2.2. Examples for sigining

2.2.1. Minimal representation for signed message

{
    "signatures": [
        {
            "algorithm": "ed25519",
            "signingKeyID": "pOTl8+/TvnZZ2tx9F6CiUD1S+mhQsV1nhlDGZosIzcs=",
            "signature": "x9ywLzYd0fzmXmHQfby9xt/fBtEqo/gldF1pyXjVpp+uQyHnYoNPxGuAGthMwIz/MRTTvELmDzxRMbD44jZWBA=="
        }
    ]
}

2.2.2. Full representation with linked signing key for signed message

{
    "signatures": [
        {
            "algorithm": "ed25519",
            "scope": [ "body", "subject" ],
            "linked": true,
            "signingKeyID": "https://example.com/keystore/johndoe",
            "signature": "MmGA6HSSeywZGn2Bf81dngALf82mPmUqk/VBMMIlXo7VO/TDBQxYymF+h80X3xb8LQ1K27LWPlPFOkIegN4mDw=="
        }
    ]
}

2.2.3. Two signatures for message

{
    "signatures": [
        {
            "algorithm": "ed25519",
            "signingKeyID": "pOTl8+/TvnZZ2tx9F6CiUD1S+mhQsV1nhlDGZosIzcs=",
            "signature": "x9ywLzYd0fzmXmHQfby9xt/fBtEqo/gldF1pyXjVpp+uQyHnYoNPxGuAGthMwIz/MRTTvELmDzxRMbD44jZWBA=="
        },
        {
            "algorithm": "ed25519",
            "scope": [ "body", "subject" ],
            "linked": true,
            "signingKeyID": "https://example.com/keystore/johndoe",
            "signature": "MmGA6HSSeywZGn2Bf81dngALf82mPmUqk/VBMMIlXo7VO/TDBQxYymF+h80X3xb8LQ1K27LWPlPFOkIegN4mDw=="
        }
    ]
}


3. Encryption
-------------

3.1. Fields with encryption

encrypted        - Keys set.
algorithm        - MUST.
scope            - MAY. Array. If absent only body encrypted.
linked            - MAY. Boolean. If set encrypting key is available for fetch by URL.
signingKeyID    - MUST. String. Base64 encoded key or URL.
recipientKeyID    - MUST. String. Base64 encoded recipient public key used to encrypt message.
nonce            - MAY. String. Base64 encoded ephemeral key. Depend on algorithm.


3.2. Examples for encryption

3.2.1. Minimal representation for encrypted message

{
    "encrypted": {
        "algorithm": "curve25519-xsalsa20-poly1305",
        "signingKeyID": "c5DoahiQb33ntqsYq7H7tdnwmhbYkTJ6gR7OIqlVaz8=",
        "recipientKeyID": "BhxRQ0l6+srSD7HqKr/NdXBHlRlPcS4RK9XlylA++TI=",
        "nonce": "tN3+/+93vgaw480OZPxbdpnNCC2zWbUH"
    }
}

3.2.2. Full representation with linked signing key for encrypted message

{
    "encrypted": {
        "algorithm": "curve25519-xsalsa20-poly1305",
        "scope": [ "body", "subject" ],
        "linked": true,    
        "signingKeyID": "https://example.com/keystore/johndoe",
        "recipientKeyID": "BhxRQ0l6+srSD7HqKr/NdXBHlRlPcS4RK9XlylA++TI=",
        "nonce": "tN3+/+93vgaw480OZPxbdpnNCC2zWbUH"
    }
}


4. Encryption and sigining examples
-----------------------------------

4.1. Minimal representation for encrypted and signed message

{
    "encrypted": {
        "algorithm": "curve25519-xsalsa20-poly1305",
        "signingKeyID": "c5DoahiQb33ntqsYq7H7tdnwmhbYkTJ6gR7OIqlVaz8=",
        "recipientKeyID": "BhxRQ0l6+srSD7HqKr/NdXBHlRlPcS4RK9XlylA++TI=",
        "nonce": "tN3+/+93vgaw480OZPxbdpnNCC2zWbUH"
    },
    "signatures": [
        {
            "algorithm": "ed25519",
            "signingKeyID": "pOTl8+/TvnZZ2tx9F6CiUD1S+mhQsV1nhlDGZosIzcs=",
            "signature": "x9ywLzYd0fzmXmHQfby9xt/fBtEqo/gldF1pyXjVpp+uQyHnYoNPxGuAGthMwIz/MRTTvELmDzxRMbD44jZWBA=="
        }
    ]
}

Sun, 16 Jun 2019 22:19:48 +0200

Max Kostikov

kostikov@zotum.net

BTW curve25519-xsalsa20-poly1305 algorithm from NaCl library in examples provides encryption and signing using the same key so no need to use additional signing for those messages.

Mon, 17 Jun 2019 02:05:13 +0200

El Dorado

mike@z.macgirvin.com

I like how the ac (openpgp) approach is well integrated with ActivityPub and the 'cryptoProtocols' element is extensible. You're writing the code here, but it would be a shame to re-invent a perfectly good wheel. I only do that when somebody hands me a square wheel and I want to roll it down a hill.

Also just to make sure you're aware that E2EE is a perfect malware delivery service, especially if you're trying to do it in the browser. You can look at our own E2EE implementation to see how I got around this. Although we have a working demo of this ability, I actually don't see much point in doing this in the browser (you can't trust that the server JS hasn't been altered) which is another reason why I'm so interested in openpgp integration and moving all of this to the desktop/device. Hubzilla supports this today by posting via API with a non-text content-type. We do not display these in the browser, but offer them for download to your device. This keeps the untrustable content completely out of your browser. It can still be used for malware delivery but this is no longer our responsibility and at least they can't steal your Hubzilla session.

I've had a number of years to think about this and have tried a number of different integrations (besides the built-in E2EE service I had openpgp working as a crude demo at one point). So I'm not trying to knock you back (not at all), but just trying to share what I've already learned. Openpgp is a clear winner because you really don't want to write desktop clients for every bloody operating system although something is needed to send/receive to/from the Hubzilla API. That's still a lot easier than dealing with multi-platform crypto. JS E2EE isn't really E2EE. It's "almost" E2EE unless all the resources used are local to the filesystem. Most crypto professionals will laugh at it, though it's arguably useful for secrets with no inherent state or monetary value.

Mon, 17 Jun 2019 11:18:57 +0200

Max Kostikov

kostikov@zotum.net

Thanks.
I share your considerations and understand caveats on JS E2EE. Indeed JS in browser have security defects from the birth no matter what crypto protocol or library used. But if we need to do all those crypto stuff at clients side (and this exactly what E2EE means) I really do not see an comprehensible alternative. Every computer or smartphone now have browser with JS and this makes a browser an universal thin (not so thin of course) client. So perhaps because of my poor knowledge in cryptography I don't understand why OpenPGP protocol is a winner here and how it help to solve all mentioned potencial problems. I'll be appreciate you for additional details.

At this moment I thinking about implementation E2EE in Hubzilla by same way how it do e.g. in ProtonMail or Mega.nz cloud when keys stored encrypted on server and fetched and decrypted by users passphrase. I believe JS version of NaCl (libsodium) cryptographic library known as TweetNaCl is fits for those needs because of small size, fast speed and audited security.

Tue, 18 Jun 2019 01:33:57 +0200

El Dorado

mike@z.macgirvin.com

@Max Kostikov - You've shown that you're quite capable of handling security issues of all kinds so just take my comment as "sharing what I know". As long as the browser page isn't served from the same domain as your Hubzilla page you should be fine. Since we can't "cleanse" Javascript when E2EE is used it makes it trivial to steal cookies if you serve it from the same domain as one where you are authenticated.

OpenPGP is available in some form on nearly every device and OS so can save you a lot of effort porting crypto to different platforms. And if you used 'ac' it would be forward compatible with both ActivityPub and Zot6 whereas a custom implementation would also need to ported to (or not allowed on) those networks. Eventually we want Hubzilla to use Zot6 by default but that's looking like less of a possibility every day because of its federation requirements. Anyway that's all I have to say on the subject. You're free to do whatever you want and I'd love to see some more modern crypto algorithms with HMAC and elliptic curve support. My only job is to tell you what I know related to the historical context of this feature within the project and then get out of the way and let you do your thing.

Tue, 18 Jun 2019 09:01:18 +0200

Mario Vavti

mario@hub.somaton.com

Eventually we want Hubzilla to use Zot6 by default but that's looking like less of a possibility every day because of its federation requirements.

I hope we can switch to zot6 with 5.0 (i guess most active hubs will be upgraded to 4.0+ by then). It is not very clear to me what still needs to happen before then and how this will affect federation (except for loosing diaspora DMs) though.

Tue, 18 Jun 2019 10:57:18 +0200 последнее редактирование: Tue, 18 Jun 2019 11:04:21 +0200

Max Kostikov

kostikov@zotum.net

It is not very clear to me what still needs to happen before then and how this will affect federation (except for loosing diaspora DMs) though.

And Friendica too and this is a good question.
Prehaps we will be able convert those messages on the fly to save this possibility.