chore: rename project quicnprotochat -> quicproquo (binaries: qpq)
Rename the entire workspace:
- Crate packages: quicnprotochat-{core,proto,server,client,gui,p2p,mobile} -> quicproquo-*
- Binary names: quicnprotochat -> qpq, quicnprotochat-server -> qpq-server,
quicnprotochat-gui -> qpq-gui
- Default files: *-state.bin -> qpq-state.bin, *-server.toml -> qpq-server.toml,
*.db -> qpq.db
- Environment variable prefix: QUICNPROTOCHAT_* -> QPQ_*
- App identifier: chat.quicnproto.gui -> chat.quicproquo.gui
- Proto package: quicnprotochat.bench -> quicproquo.bench
- All documentation, Docker, CI, and script references updated
HKDF domain-separation strings and P2P ALPN remain unchanged for
backward compatibility with existing encrypted state and wire protocol.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -6,7 +6,7 @@ compromised, past session keys cannot be recovered.** In other words, an
|
||||
attacker who obtains today's long-term key cannot use it to decrypt messages
|
||||
recorded yesterday.
|
||||
|
||||
quicnprotochat provides forward secrecy at two independent layers: the transport
|
||||
quicproquo provides forward secrecy at two independent layers: the transport
|
||||
layer and the application layer. Even if one layer's FS mechanism is defeated,
|
||||
the other continues to protect message confidentiality.
|
||||
|
||||
@@ -28,7 +28,7 @@ In each TLS 1.3 handshake:
|
||||
|
||||
Because the ephemeral keys exist only for the duration of the handshake,
|
||||
compromising the server's long-term TLS certificate key (currently self-signed
|
||||
in quicnprotochat) does not reveal past session keys.
|
||||
in quicproquo) does not reveal past session keys.
|
||||
|
||||
## Application Layer Forward Secrecy
|
||||
|
||||
@@ -54,7 +54,7 @@ This deletion is the mechanism that provides forward secrecy: once old epoch
|
||||
keys are erased, messages encrypted under those keys cannot be decrypted, even
|
||||
if the current group state is compromised.
|
||||
|
||||
In quicnprotochat, epoch advancement occurs when:
|
||||
In quicproquo, epoch advancement occurs when:
|
||||
|
||||
- `add_member()` is called, which creates a Commit and calls
|
||||
`merge_pending_commit()`.
|
||||
@@ -91,7 +91,7 @@ HPKE init keys.
|
||||
|
||||
## Layered Forward Secrecy
|
||||
|
||||
A distinctive property of quicnprotochat's design is that forward secrecy
|
||||
A distinctive property of quicproquo's design is that forward secrecy
|
||||
operates at two independent layers:
|
||||
|
||||
```text
|
||||
@@ -135,7 +135,7 @@ unless they also break the transport encryption.
|
||||
Signal's Double Ratchet protocol also provides forward secrecy, but the
|
||||
mechanisms differ:
|
||||
|
||||
| Property | Signal Double Ratchet | MLS (quicnprotochat) |
|
||||
| Property | Signal Double Ratchet | MLS (quicproquo) |
|
||||
|----------|----------------------|---------------------|
|
||||
| Scope | Pairwise (1:1 sessions) | Group (n-party) |
|
||||
| Ratchet granularity | Per message (symmetric ratchet) + per DH round (DH ratchet) | Per epoch (Commit) |
|
||||
|
||||
Reference in New Issue
Block a user