Re: [GNUnet-developers] email-like service atop of GNUnet?

[Christian Grothoff]

On 10/21/2012 05:59 PM, Ivan Shmakov wrote:
> > > > > > Christian Grothoff<address@hidden>  writes:
> > > > > > On 10/19/2012 07:58 AM, Ivan Shmakov wrote:
>
>         [Moving to address@hidden
>
> […]
>
>   >>  If so, is it possible to use the public key of the same key pair to
>   >>  encrypt (directly, or using a block cipher, in a usual way)
>   >>  arbitrary data to be “sent” securely to the namespace's owner?
>
>   >  Technically yes, except that no API exists for you to do so.
>
>   >>  Also, could there be a way for the namespace's owner to search for
>   >>  the data sent to him or her that way?
>
>   >  Well, again we'd need to define how this would happen (i. e. under
>   >  which key the owner would need to search,
>
>         There may be a privacy issue to consider, BTW.  Namely, I've got
>         an impression that keyword searches are, to an extent, “public”,
>         in the sense that a node learns at least a part of the searches
>         it takes part on behalf of the other nodes (and perhaps the
>         results of such searches as well.)  And if such a search
>         contains a public key (which corresponds to a particular
>         identity), that may be a problem.

You might want to read
https://gnunet.org/bugs/view.php?id=2564
which still needs to be implemented.

>         Probably even worse is that an adversary may search for the
>         messages sent to a particular identity by him- or herself.
>
>   >  what the format of the data is, etc.).
>
>         Conceptually, we already have a facility to transfer arbitrary
>         binary data, and a symmetric key-encrypted message is certainly
>         such a data.  What we'd need is the format for the “pointer”
>         messages, containing a reference to the (encrypted) message, as
>         well as linking public keys to public key-encrypted symmetric
>         keys of the recipients (and, perhaps, the public key of the
>         sender, and an encrypted digest of the original, unencrypted
>         data, to form a digital signature), like (speaking X.680):

You've lost me here.  You've never fully explained what you're trying to 
do.  Based on what you write below, I guess it is some variant of 
pseudonymous E-mail?  If so, in what way does Mixminion not solve your 
problem?

Happy hacking!

-Christian


> -- SIZE (512/64) OF BIT/OCTET STRING?
> Hash    ::= OCTET STRING
>
> -- SIZE (XXX) OF BIT/OCTET STRING?
> Key     ::= OCTET STRING
>
> -- PrivateKey      ::= Key
> PublicKey       ::= Key
> SymmetricKey    ::= Key
>
> MessageSignature    ::= SEQUENCE {
>      PublicKey           signerPublicKey,
>      Hash                encryptedPlainContentHash
> }
>
> KeyData ::= SEQUENCE {
>      -- FIXME: there has to be a nonce
>      SymmetricKey        symmetricKey,
>      -- here, MessageSignature is only accessible to the recipients, and
>      -- may even be accessible only to specific ones, or it may be signed
>      -- using different identities for different recipients, etc.
>      MessageSignature    messageSignature        OPTIONAL
>      -- may also contain a SEQUENCE OF Hash for the pointers sent
>      -- previously, so that the recipient may learn of the ones he or she
>      -- has missed
> }
>
> KeyDataMapEntry ::= SEQUENCE {
>      PublicKey           recipientPublicKey,
>      OCTET STRING        encryptedKeyData
> }
>
> KeyDataMap      ::= SEQUENCE OF KeyDataMapEntry
>
> MessagePointer  ::= SEQUENCE {
>      -- NB: the hash may be moved under KeyData, for good
>      Hash                encryptedContentHash,
>      KeyDataMap          keyDataMap
> }
>
>         Note, however, that thanks to the inclusion of
>         recipientPublicKey in the open, such a format isn't all that
>         good at preserving privacy.  (In the sense that an adversary may
>         learn that a message was sent to a particular recipient or
>         recipients, linking those to one another.)
>
>         Also to note is that the use of a single symmetric key together
>         with one or more pointer messages (each of which could contain
>         one or more key-data map entries) corresponds to the use of Cc:
>         in that the recipients may learn of one another.  (In this case,
>         recipients may be added to a message at any time.)  OTOH, the
>         use of distinct symmetric keys (with a single pointer message
>         per key, and thus per recipient) corresponds to the use of Bcc:.
>
>         That being said, should we move encryptedContentHash under
>         KeyData (thus reducing MessagePointer to KeyDataMap), and allow
>         the intermediate nodes to shuffle individual KeyDataMap entries
>         around, we'll make the task of relating the recipients to one
>         another much harder for an adversary…