[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Grothoff
Subject: Re: [GNUnet-developers] email-like service atop of GNUnet?
Date: Mon, 22 Oct 2012 10:04:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4

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
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!


Hash    ::= 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…

reply via email to

[Prev in Thread] Current Thread [Next in Thread]