A forwarding xor reading capability?

[John Carlson]

I want an originating service/client to grant a gateway server a message-read-xor-forward capability.  But this seems dangerous.  On the other hand, it’s just one message .  Maybe performing the message-read capability revokes the message-forward capability automatically.  And using the  forwarding-capability revokes the read-capability (locally) automatically.

I realize that the message can be sent anywhere. Once the read capability is invoked, the forward capability is automatically revoked.   There’s a choice between reading and forwarding.   So one either reads, and forwarding is revoked, or one forwards without reading.

I don’t know if this is practical or what it’s called.   It sounds like anti-tampering or sealing and unsealing.  That is, if the servers do their jobs forwarding, no tampering will be detected by recipient—the message-read capability won’t be revoked until the recipient reads the message.

I am unclear if I can multicast this.   I assume read doesn’t destroy the read capability. And the  forward capability does not revoke a forward capability.  I do have a multiple party encryption scenario.

John 

[Alan Karp]

I'm not clear about what you want to achieve.  Couldn't the recipient tell the forwarder the message contents?

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEmY4psjbCUATubuKOqS-29T-r0psaj3Fjkp4Le-yL7e9g%40mail.gmail.com.

[Raoul Duke]

i don't understand why messages wouldn't be encrypted if one has more than zero concerns about the message pathway?

[Matt Rice]

Alan, I kind of struggle to understand your statement (which came
first the chicken xor...), are you saying you can
implement forwarding by using read, then copy the data into a new cap,
and forward that?

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1znLD02RGNON2v9Zuw2CaaoOoh%3DH016Bagrn-Vw4h10w%40mail.gmail.com.

[John Carlson]

They probably would be encrypted, and yes encryption used correctly can detect tampering.  Perhaps I’m more concerned about possible encryption gaps between the load balancer and the backend.  Everyone’s dirty secret!   If the load balancer chooses “read” then they won’t be able to “forward”. Kind of like for an acceptance test.

John 

On Fri, Feb 13, 2026 at 10:49 AM Raoul Duke <rao...@gmail.com> wrote:

i don't understand why messages wouldn't be encrypted if one has more than zero concerns about the message pathway?

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAJ7XQb6_jPFB5jWfCbkxALyu4Fx_F_MW8Ebvvk%3DrjLGmMWV%2BAg%40mail.gmail.com.

[John Carlson]

I think the main goal is defending against man-in-the middle attacks, which PKI does adequately (well, somewhat).  The problem is that some forms of HTTP/S don’t use TLS for the last leg of security on the backend, from the load balancer and the app/web server.   Say I could craft something to detect that as part of an acceptance test.  The key would be to employ encryption and capabilities together.  If something comes to the client or server with no-read capability, one would understand that it had been read, and not just forwarded.

It would be critical for the load balancer to only use the message-forward capability and not the message-read capability.

It’s understood that the byte stream is available at lower, perhaps more secure (encrypted) lower levels.  At that level, probably quantum anti-tampering could be deployed. Maybe not presently, but a potential future.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1znLD02RGNON2v9Zuw2CaaoOoh%3DH016Bagrn-Vw4h10w%40mail.gmail.com.

[Raoul Duke]

do you really only want to prevent, or also definitely detect? if the
message is encrypted with back-end's key before then going through
HTTPS, wouldn't that keep things safe, albeit not guaranteed tell you
about siphoning?

[John Carlson]

One of my test installations is HTTP from the load balancer to the app server, and I’m not exactly happy about that.  I will have to figure how to encrypt a second time in hopes of achieving security.  No, I’m happy about that either.  Currently, the traffic is JSON across websockets.  My initial idea was to use HTTPS with bearer tokens, etc.

[Alan Karp]

I'm trying to understand the threat model.  What practical problem does the XOR property address?  Who trusts whom with what to do what with it?  Are there simple workarounds to the restrictions?

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFon-8n%2Bpm6OOuGSbAoRwkYRnhkYZNKMNYrzdaN%3DhDefvg%40mail.gmail.com.

[Matt Rice]

Oh, I get what you're saying now, the
"Couldn't the recipient tell the forwarder the message contents?" is
something to the effect of
"When the recipient invokes read, they can still share the result with
the forwarder who had read revoked".
Not the incomprehensibly circular "implement this by having the
recipient send the forwarder the data to be forwarded to the
recipient".

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0NQ1ot_gpiFZsY7hd7qUDgQ6ao3jSWhnAGQvebR4KX%3Dg%40mail.gmail.com.

[John Carlson]

I think it’s a simple choice between either reading XOR forwarding.  Yes, once reading, the gateway could send on the original capability.  That’s why read needs to be revoked when the message is read.

Again, it’s about acceptance testing to see whether a load balancer or other gateway is doing some kind of man-in-the-middle attack.  If a read capability is given, will the system use it?  Or will it forward the capability properly. 

I think I made a mistake though.  Once the forwarding is done, the read capability should only be revoked on the gateway.  I don’t think that is possible.  If the read is done,  the read-forward-message capability should be revoked globally.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0NQ1ot_gpiFZsY7hd7qUDgQ6ao3jSWhnAGQvebR4KX%3Dg%40mail.gmail.com.