Confidentiality of z2z messages

[mistfpga]

I need some help please.

I am pretty sure i know the answers to most of these, but id like as much feedback as possible. (a lot is answered here - The Encrypted Memo Field - Electric Coin Company)

I am trying to work out extra messenger functionality and the implications of it.

I know some of these suggestions go against what a cryptocurrency is about. I am trying to explore the messenger side. It will probably have to be a sidechain.

as I have said before im working on some messenger stuff.

For me a very important part of hard encrypted messaging is plausible deniability. Something that is lacking from all modern messenger apps that I can find. They have workarounds, but they are not great.

An example of something I consider good, Pidgin + OTR

All of these features are key.

Off-the-Record (OTR) Messaging allows you to have private conversations over instant messaging by providing:

Encryption

No one else can read your instant messages.

Authentication

You are assured the correspondent is who you think it is.

Deniability

The messages you send do not have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, during a conversation, your correspondent is assured the messages he sees are authentic and unmodified.

Perfect forward secrecy

If you lose control of your private keys, no previous conversation is compromised.

I cannot find a method for Forward secrecy and Deniability (although you could use the security by obscurity angle and say you cant prove i sent the message - although meta data leaks and correlation attacks will probably disagree and prove you are the sender)

If, for example, someone sends me a z2z transaction with “Thanks, please ship to xyz”

As a reciever of a z2z message:

• If I have to give the view key to the tax man will they also get the note? is there anyway I can stop this?
• If I move the funds, does the note ever get expired? (is it only checkpoints and upgrades?)

As a sender:

• If I do not trust the receiver I would like to expire the message after a time delay

• If I want to send the same message to a few people but not have one view key, i want them to have their own so the messages can expire on read.

the only ways i can see is to be able to do this is to disassociate the privkey but this could cause loss of funds. or to be able to overwrite the note part of the transaction with a subsequent note. (this second option actually gives a lot more usability to messaging.)

In general:

• If the network gets compromised are all notes exposable?
• Is the attack surface for this the same as to take over the network?
• What about forks, what is the risk here?

I have a few different approaches to solve this, but none are elegant and most are beyond my coding skill level. my current approach is to have a merge mined messenger only chain, but that has its own issues.

tagging @NighthawkApps and @adityapk00 - do you think this could be solved on a wallet software level without need for changes to the protocol?

tagging @Shawn and @amiller - Who do I address questions to for the foundation as to future protocol development and if things can be on the roadmap? (like revocation certificates, overwriting old notes with new ones.)

And for those who dont care about the messenger aspect of it, 512bytes is long enough for a Key Exchange Key to set up secure communications devices/channels and solve some of the issues with D-H or PKI. You need the ability to disable the key should the device get compromised.

[Shawn]

Interesting ideas but I will admit most of it is above my head.

And Andrew or @antonie would know better about ZF (Zebra) protocol development for future roadmap things.

[sarahjamielewis]

It seems there is some confusion around the technical definitions of Deniability and Forward Secrecy so I am going to link this excellent paper by Unger et al http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf to help with definitions.

For me a very important part of hard encrypted messaging is plausible deniability

See section II(d) and V. of the paper for a discussion the different kinds of deniability, achieving each has tradeoffs and complexities:

Message Unlinkability: If a judge is convinced that a participant authored one message in the conversation, this does not provide evidence that they authored other messages

Message Repudiation: Given a conversation transcript and all cryptographic keys, there is no evidence that a given message was authored by any particular user.

Participation Repudiation: Given a conversation transcript and all cryptographic key material for all but one accused (honest) participant, there is no evidence that the honest participant was in a conversation with any of the other participants.

The paper only considers offline deniability. Online deniability is pretty tricky and many other desirable properties (e.g. Authentication) tend to break it (at least partially) - but there are some schemes that attempt to achieve e.g. “deniable authentication” which may be the property you are seeking.

I cannot find a method for Forward secrecy and Deniability

Forward-secrecy is better defined as “A protocol provides forward secrecy if the compromise of a long-term key does not allow ciphertexts encrypted with previous session keys to be decrypted” -
you can’t achieve forward secrecy with a single key base, and you certainly can’t achieve it through some ad-hoc message-replacement or overwriting (which will always allow certain adversaries to
record the previous public data should the keys ever become available). To obtain forward secrecy you need a way to “migrate” keys (while maintaining authenticity).

Doing this while protecting metadata is still a challenge, because key-management among a number of parties churns out a lot of overhead messages - which in turn results in more property-tradeoffs e.g. resilience to dropped/reordered messages v.s. unlinkability.

Memos, by construction, have sender-deniability, there is nothing that (cryptographically) ties them to the sender. Anyone, including the recipient, can construct a transaction that given a viewkey, decrypts to a valid message (the corollary to this is that anyone can send themselves funds and there is no way to distinguish between someone sending themselves funds and someone else sending them funds).

The act of placing these messages into the consensus may create metadata which ties the sender to the transaction containing the message. You need additional protocols to secure against metadata analysis (like a mixnet or onion routing) but metadata-resistance is a separate property from cryptographic deniability.

(While we are on the topic, as stated above, Authentication is probably one of the harder properties to achieve if you want bi-directional properties while maintaining some of the nicer underlying properties e.g. sender-deniability)

[mistfpga]

Hi sarah,

Thanks for the link. I haven’t read it all yet, it is very interesting though - is it specific to the usa?

I agree the terminology i used was not the best, it is a direct quote from the OTR plug-in marketing bit.

@sarahjamielewis

“deniable authentication” which may be the property you are seeking.

Might be, still reading you link.

I think I have caused confusion because I am asking about a few different things and not making a proper distinction.

For zcash:

• I would like the ability to expire memos from viewkeys or viewkeys themselves. Either as a reader, or as a sender. Replies cause issues for anything but single use messages. I cannot see a viable way to do this without being able to disassociate a privkey from a pubkey.

Revocation, MEK,DEK and KEK and :

• I want to use z2z as a black key, and the memo as a red key. Authentication for my needs in this case is desirable.

metadata is not an issue for this. It is just to establish a black channel over red networks.

This schema would also require a DEK (Data Encryption Key) and a MEK (Master Encryption Key) - zcash already has most of this.

Adding this functionality to zcash would drop the cost to make commercial grade datacryptors affordable to everyone, this would give them application from games to tv channel encryption boxes to PoS terminals to office workers working from home. But it must have protocol level revocation certificates. (this could be a sidechain i suppose)

Then there is my messaging stuff, which has different requirements and is not meant for the mainchain:

@sarahjamielewis

Memos, by construction, have sender-deniability, there is nothing that (cryptographically) ties them to the sender. Anyone, including the recipient, can construct a transaction that given a viewkey, decrypts to a valid message (the corollary to this is that anyone can send themselves funds and there is no way to distinguish between someone sending themselves funds and someone else sending them funds).

Replies break this chain. You have to have access to the privkey for a continued authenticated conversation. every message is a signed transaction. like a signed and encrypted pgp message, so you get authentication even if you dont want it. Which is why I need a way to remove the messages, otherwise key management will become an nightmare. This might be able to be solved in software. I have a few ideas, not sure how viable they are though. (this does sound like deniable authentication)

One of my ideas was to try to get this working just in the mempool and not commit the message to the blockchain. In this case writing overwriting the memo is useful.

The message can be sent and read by the messaging software then zeroed out when confirmed into the blockchain. This really needs to be at the protocol level, or, actually can i over write a memo before it is confirmed? If I change the fee does it change the memo too? Even if it doesnt I can code that myself. I would still need an extra opcode that says dont mine this transaction until xyz condition is met. making deliberately non mineable transactions seems a little bad. I am not sure if this will lead to anything but I am having fun exploring the idea.

this doesnt completely remove the need for disabling viewkeys but it does remove provable historical evidence. So if I give someone the viewkey after the fact they will not see the messages.

The act of placing these messages into the consensus may create metadata which ties the sender to the transaction containing the message. You need additional protocols to secure against metadata analysis (like a mixnet or onion routing) but metadata-resistance is a separate property from cryptographic deniability.

yeah metadata is out of scope for the moment. I just trying to get basic functionality thought out.

Authentication is probably one of the harder properties to achieve if you want bi-directional properties while maintaining some of the nicer underlying properties e.g. sender-deniability

yup. couldnt agree more.

you can’t achieve forward secrecy with a single key base, and you certainly can’t achieve it through some ad-hoc message-replacement or overwriting (which will always allow certain adversaries to record the previous public data should the keys ever become available). To obtain forward secrecy you need a way to “migrate” keys (while maintaining authenticity).

I think I have confused you here, I am not trying to do this with the zeros, that was for the real time mempool messaging which doesnt address forward security and only uses a single keybase. It protects data at rest once it is in the blockchain, it doesnt stop someone from storing all the mempool stuff. Revocation certificates are controlled by a key pool or MEK and will help with that problem.