View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003573 | secushare | psyc | public | 2014-12-10 23:16 | 2019-02-12 09:19 |
| Reporter | cy1 | Assigned To | |||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | acknowledged | Resolution | open | ||
| Summary | 0003573: Need Private Messages | ||||
| Description | GNUnet has routines for encryption based on a (paillier) keypair, and it has routines for creating files and blocks, but there is no way I can see to encrypt a block with someone's keypair. The only asymmetric encryption that ever happens is for the direct connection between peers. Thus you can publish a file with a keyword that must be guessed, which can act like a password, and you can publish a file under your own namespace, which must be known before anyone can decrypt it, but you can't publish a file for someone else's namespace, the file then only being decryptable by the owner of the namespace keypair. So in short, there is no way to save a private message in-band, and there should be. Perhaps a block like an SBlock, with a key and query hash, but instead of encrypting it to a keyword (KBlock), or encrypting it using the hash of the public key of a namespace as a symmetric key (SBlock), you encrypt it USING the public key of a namespace, then include that public key's hash after the encrypted part, with maybe a timestamp. Then someone could query peers for any block that matches their public key, and is more recent than the last time they checked. That someone alone could decrypt that block, getting the key and query hash for the actual IBlock of the message, and maybe some metadata. I don't know if the ECDSA keys are bad at encrypting stuff and can only be used for signing/verification. If so then the paillier keys could be used instead, not of the GNUnet peer itself, but of the identity being targeted. It'd be a strategy in the style of Gnupg in that case, with each identity being a pair of keypairs, one for signing and one for encryption. When publishing that identity, it's both public keys from each keypair, though still indexed by the hash of the public signing key. People getting it would therefore also receive the public encryption key, and could prepare private messages by the above scheme. Actually to be fair, I'm sort of shaky on how you publish an identity using the file sharing service. I sure can't find any identities via gnunet-search. I guess the public key is just included in the SKS URI? Then how does the human readable nickname get propagated? But, if we needed a second public key for encryption, it would be relatively straightforward to publish the pair of public keys in the namespace, letting anyone who searches for gnunet://sks/mysigningkey/someidkeyword to get that encrypting public key. Yes I know you can just do gpg --recipient $fingerprint --encrypt file; gnunet-publish -t pm.$gpgfingerprint file.gpg; but using Gnupg for a redundant layer of encryption is sort of inelegant, and I'd prefer gpg to remain the reliable fallback option, not the only option. gnunet://fs/sks/SYSEB6KT5RGZ7T3MFGQ9XG98MRBZ6QA7CY6F4MFMHASA5N5XSV2G/pmrant | ||||
| Tags | No tags attached. | ||||
|
|
I'll respond to the various points in separate notes. To make a message so that only the owner of an identity/namespace/zone can decrypt it, you should adapt GNUnet's ECDHE logic to essentially leave out the 'ephemeral' nature on one side, using effectively ECDH. Basically, suppose Bob wants to send a message to Alice. Bob creates an ephemeral ECC key pair, then computes a shared secret using the private key of the ephemeral key and Alice's public key (ECDH). The shared secret can then be used to encrypt-and-mac the payload. If needed, Bob can sign the ephemeral key with his identity to prove to Alice that the message is from Bob. Yes, our API lacks two function call to do this, but all you have to do is implement two variations of GNUNET_CRYPTO_ecc_ecdh with mixed Ecdhe/Ecdsa pub/priv keys as arguments. I believe the result should be cryptographically still secure, but feel free to consult DJB on mixing ECDH and ECDSA using the same key. |
|
|
Peers in FS discover pseudonyms via UBlocks, those are blocks that contain a URL, and if the URL is of the form gnunet://fs/sks/ZONEKEY/, then we just learned a pseudonym/zone/identity, plus some meta data (also in the UBlock). You may encounter UBlocks in directories or when you do a keyword search. |
|
|
Finally, the real issue with "responding" to the owner of an identity is not how you encrypt TO that person, but how you notify the owner. That is tricky, as unsolicited messages are also known as SPAM. So the real answer why there are no 'private messages' in file-sharing is that file-sharing follows a query-response paradigm, while you need something else for unsolicited messages. While I do think we need to (eventually) have a feature to do this, I'd not consider this part of 'file-sharing' for this reason. It's a different kind of application. Naturally, GNUnet's identity service would still tie everything together, so it would make sense to learn about a user's namespace/identity via file-sharing, and then use the identity/address for messaging. |
|
|
Oh, notifying the owner wouldn't be necessary. Generally most 'private message' applications for a program like fs will just regularly poll a keyword under which people submit messages they want you to read. A separate application would be fine too I guess... but it'd have to have a way to send around arbitrary length messages efficiently in a way that could work using other intermediaries to hold them when in transit. something like a "hash tree" maybe where files are broken into blocks and a tree of their structure is inserted in parallel. plus things like multimedia and images would be nice, with the media separate from the message itself and the links to them packaged together in a sort of "directory" file. You also need a way to save all this on disk, in a hopefully secure and redundant as possible fashion, and you might want to expire messages after a while to make room for new ones. fs covers all that, so if you don't want to use fs you have to redo it some other way. Seems easier to me to just to add public key encryption to fs. I might recommend a separate application, but only for pushing message streams, some sort of pub/sub interface of lists of CHKs, with the messages themselves still contained entirely within the fs. So like, gnunet-publication would notify the client, which would query gnunet-fs to retrieve the message contents for display. Though then there's the problem of having to figure out how this pub/sub application can safely notify the recipients of a message without possibly compromising their location. Just sending messages to a GNUnet peer whose address/location/ISP is known wouldn't allow people to talk with people they don't already trust, and would let one person's security being compromised also endanger everyone they can send messages to. which again, fs takes care of, because you can't tell who published a file (or message) under a particular key, so you can't betray that person to your aggressor. |
|
|
Well, I could always hack something with storing publication streams as opaque files. Public key cryptography only ever encrypts the symmetric session key anyway, which is roughly equivalent to encrypting the stream of CHKs, so even if gnunet-fs itself doesn't encrypt with public keys, it still protects the data behind a symmetric key. That could still be problematic in that an adversary who knew the exact contents of the private message they were looking for could tell who received it (because of convergent encryption), but hacking in a timestamp field to the messages would pretty much do away with any problems there. Sure it'd be more elegant to just use a different key in the CHK than the hash of the unencrypted content, but that's not do-able currently, and embedded timestamps can be useful in their own right. |
|
|
But then anyone could tell how many messages you were receiving, just by searching for your key like you would... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-12-10 23:16 | cy1 | New Issue | |
| 2014-12-11 15:50 | Christian Grothoff | Note Added: 0008667 | |
| 2014-12-11 15:51 | Christian Grothoff | Note Added: 0008668 | |
| 2014-12-11 15:55 | Christian Grothoff | Note Added: 0008669 | |
| 2014-12-11 15:55 | Christian Grothoff | Category | file-sharing service => other |
| 2014-12-11 23:19 | Christian Grothoff | Priority | normal => low |
| 2014-12-14 16:19 | Christian Grothoff | Status | new => acknowledged |
| 2014-12-14 16:19 | Christian Grothoff | Category | other => PSYC service |
| 2014-12-30 22:44 | cy1 | Note Added: 0008742 | |
| 2014-12-30 22:48 | cy1 | Note Edited: 0008742 | |
| 2015-01-03 22:30 | cy1 | Note Added: 0008750 | |
| 2015-01-03 22:38 | cy1 | Note Added: 0008751 | |
| 2019-02-12 09:16 | Christian Grothoff | Project | GNUnet => secushare |
| 2019-02-12 09:16 | Christian Grothoff | Category | PSYC service => General |
| 2019-02-12 09:19 | Christian Grothoff | Category | General => psyc |
