This shows how to generate a zaddr at run-time and use it correctly,
I am sure Denio will be happy! This method will work for Sietch in SDL,
but actually I need to throw all this code away for this exact use case.
At least Denio can use it!
What I did was to study how the code to generate new zaddrs in the Receive
UI works, and this is the TLDR: It uses a chain of callbacks to assure that
class-level data it stores (the RPC::zaddresses variable) always has data
when it goes to read it. I did the lazy thing and pushed everything into
a single callback, which is equivalent.
The core problem now is that a brand new zaddr will not have any funds,
and is unable to pay the default tx fee. We must always make sure we have a
pool of these addresses, at startup, and make sure they have some funds,
which can be periodically checked and "topped up". Once we have that,
we will pull a new address from that pool if we add a new HushContact, instead
of this current run-time generation of a new zaddr.
This UUID is only needed to be unique for any pair of
(Alice,Bob) having a conversation. In the future when
group chats are supported, we will need them to be unique
for all users in the chat. We do not rely on this ID
to be globally unique for all Hush chats in any way.
Without a conversation id, Charlie the attacker can
attempt to impersonate Alice or Bob if he knows some or
all of the zaddrs involved. If the conversation id was
predictable, such as the SHA256 hash of both zaddrs,
Charlie could predict it if he knew both zaddrs,
which is likely to happen in many attack scenarios.
If cid had a small number of possible values, the attacker
could "grind" all of them and eat the cost of the extra
tx fees, so cid must have a large state space. QUuid gives
us essentially a random 128bit number, which is twice
the protection as a random int64.
This mitigation will not be needed once HIP304 and
z_signmessage/z_verifymessage are complete, which allow
us to have fully authenticated and signed messages from zaddrs.
Duke Leto
miodragpop