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

[Ivan Shmakov]

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

        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):

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

[…]

-- 
FSF associate member #7257