Repository where nkls researches and experiments with mixnet things
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

261 lines
9.1 KiB

New approach on pEpMixnet, starting 09/22
Ephemeral work name is "Moulinex":
ATM mainly Papers, Notes (and Containers)
What do we want to do?
Goal 1: Add the ability of onion routing to the pEpEngine.
And test it.
Make it usable.
Goal 2: Make and test libpox.
libpox reimplements parts of toxcore.
We use it as a transport for onion packets.
Goal 3: Put it all together.
Test it, and make something useful of it.
Goal 4: Add mixnet specific things, like packetizing, padding and pooling
This is the hardest part.
Questions and answers:
Question: In an onion packet,
what does the header of an inner message look like,
the part of the onion where the next hop is defined?
We should not reinvent the wheel. Is there a standard
or specification for that?
Read this: papers/Camenisch-A_Formal_Treatment_of_Onion_Routing.pdf
(Chapter 3)
(Chapter 3.3)
Question: When an onion packet is sent via many peers,
how can the sender find peers to use?
Should it use only peers it already knows,
or also peers its friends know?
Or should there be a centralized list of valid peers?
Additional Thoughts:
- Always consider the threat model
- As far as possible, don't reinvent the wheel
- Be happy and have fun :D
Positrons EMail:
Hello Nkls.
I was a little surprised at pEpCoCo when you spoke about me implementing
onion routing in the Engine. Volker has (independently) noticed the
issue from the document at ,
and has explained me the issues so that I can relate to you.
You will be in charge of implementing this part in the engine, but of
course I am there to help you.
--> OK.
The Engine is complicated. We can explore it together if you have
questions; better if you write me in advance and give me a little time
to research. Many things are new for me as well.
The general plan
We would like to first add support for onion routing; that requires
relatively simple Engine changes. After that, building on onion
routing, we can add mixnet support.
--> Agreed.
The transport system, differently from what I was thinking, is quire
orthogonal to all of this: the changes do not involve the transport
system but the current API from message_api.c / message_api.h , which
will keep working anyway.
Onion routing
The idea is not difficult.
Alice wants to send a message to Bob.
In order to do that she selects N intermediate hops (non-own identities)
h1..hN, all known to Alice and at least "yellow".
Alice first encrypts the message to Bob, as she would normally do
without onion routing.
In the resulting encrypted message Alice changes the outer-message
* the "From" field will be hN;
* the "To" field does not need to change: it is Bob.
Then Alice encrypts the message *again* (calling encrypt_message with a
new flag [0] to be added to PEP_encrypt_flags).
Alice takes the resulting doubly-encrypted message, and again changes
the outer-message headers:
* the "From" field will be hN-1;
* the "To" field will be hN.
... and so on, up to the outermost layer:
* the "From" field will be Alice:
* the "To" field will be h1.
Now, we want that Alice be not identifiable in the intermediate hops.
For this purpose she will use temporary own identities (to be created
and then immediately destroyed after use) with new keys during this
onion encryption process.
It might be possible for an attacker to estimate the stage of an
intercepted message from its size (decreasing at each hop); let us
currently ignore the issue.
--> For me, padding is a mixnet problem. We should leave it for now.
The decryption side
This is simpler.
On the decryption side each hK intermediate hop will strip one layer,
find an encrypted message, and just send it forward to the next hop with
At the last stage Bob will obtain a decrypted message from Alice to him.
--> QUESTION: How does each hK differ between "onion packets to decrypt and send on to the next hop" and "i am the last hop"?
Other work in progress on the Engine
The next Engine releases will be based on the master branch: previous
released were from the quite different Release_2.1 branch, which is now
being finally abandoned.
I am currently working on a temporary branch named newsequoia2022 , to
be cleaned up with brutal history rewritings and then merged into
The changes involved are not large and you can already play with master
without waiting for me to merge, with one caveat: in the newsequoia2022
branch I renamed the function encrypt_message to
encrypt_message_possibly_with_media_key, and wrote a new encrypt_message
calling encrypt_message_possibly_with_media_key. You may be surprised
by this change when we merge, but that is essentially all: the other
changes should not conflict with what you do.
[0] The new flag is not conceptually important and in an ideal world
should not be needed. We want to maintain the current behaviour
with applications which may call encrypt_message multiple times,
possibly expecting failure on an already-encrypted message.
We should just implement the new behaviour only when the flag is
Notice that there already exists a flag named
PEP_encrypt_reencrypt . That is unrelated; I am sorry for the
confusion. It is used in encrypt_to_self, as a trick for
implementing Subject protection. We could even rename the existing
flag, which is not used out of the engine.
If you want to meet over jitsi or something similar we can agree on a
day. You prefer afternoons, and those are fine for me as well.
Luca Saiu
* p≡p Foundation:
* My personal web site:
This is helpful:
68 * <!-- encrypt_message() -->
69 *
70 * @brief Encrypt message in memory
71 *
72 * @param[in] session session handle
73 * @param[in,out] src message to encrypt - usually in-only, but can be
74 * in-out for unencrypted messages; in that case,
75 * we may attach the key and decorate the message
76 * @param[in] extra extra keys for encryption
77 * @param[out] dst pointer to new encrypted message or NULL if no
78 * encryption could take place
79 * @param[in] enc_format The desired format this message should be encrypted with
80 * @param[in] flags flags to set special encryption features
81 *
82 * @retval PEP_STATUS_OK on success
83 * @retval PEP_KEY_HAS_AMBIG_NAME at least one of the receipient keys has
84 * an ambiguous name
85 * @retval PEP_UNENCRYPTED on demand or no recipients with usable
86 * key, is left unencrypted, and key is
87 * attached to it
88 * @retval PEP_ILLEGAL_VALUE illegal parameter values
89 * @retval PEP_OUT_OF_MEMORY out of memory
90 * @retval any other value on error
91 *
92 * @warning the ownership of src remains with the caller
93 * the ownership of dst goes to the caller
94 *
95 * enc_format PEP_enc_inline_EA:
96 * internal format of the encrypted attachments is changing, see
97 *
98 *
99 * Only use this for transports without support for attachments
100 * when attached data must be sent inline
101 *
102 */
This also:
185 typedef enum _PEP_enc_format {
186 PEP_enc_none = 0, // message is not encrypted
187 PEP_enc_pieces = 1, // inline PGP + PGP extensions, was removed
188 PEP_enc_inline = 1, // still there
189 PEP_enc_S_MIME, // RFC5751
190 PEP_enc_PGP_MIME, // RFC3156
191 PEP_enc_PEP, // pEp encryption format
192 PEP_enc_PGP_MIME_Outlook1, // Message B0rken by Outlook type 1
193 PEP_enc_inline_EA,
194 PEP_enc_auto = 255 // figure out automatically where possible
195 } PEP_enc_format;