@emenel the sqlite db for signal is because apps have restricted access to anything. what it provides is mapping from the byte serialization of a pubkey to the associated sessions. and in fact, i think i found that kinda wrong even for my prototype, since each session is distinct from the originating identity (bc each DH handshake is another set of completely new keypairs). in fact, i forget whether the identity key is even exposed at all........because i was also using the sealed sender approach which does tag with the sender id (but encrypted with another key)

sealed sender is kind of a hack for the server model and what i analogized to onion routing (onion packing?) works both ways, no new crypto

@emenel sorry the reason i mention all this is because double ratchet message chains having forward secrecy is something the pgp approach needs and we can do safely (not quickly or easily, but it's mature enough now imo)

there is another goal after that

@emenel and it ends up being a whole thing, but basically anonymity is possible and not difficult to codify and cryptographers don't wanna do it, because academic crypto is boring and also captured

and the work i can find on tor and i2p does not have any theory of this--the i2p paper i could find was terrible and i doubt it was representative.

but anonymity and ddos resistance are.....not in conflict

@emenel which is: you can maintain these negotiated sessions with specific peers through completely ephemeral identities, and define a source routing protocol through them. this is bootstrappable, so you can discover peers from B->C, C->D, further--although at this point it becomes significant to distinguish:

• node identity
• user identity
• key identity

maybe more or less. but this is not yet quite enough

@emenel but with source routing you can define this onion-linked chain where everyone says yeah i went to the key signing party and nobody knew you, because "you" are an abstraction, and you can ask them for updates on the status of your datagram.

btw: datagram = fixed-size as pouzin defined it. vint cerf intentionally took his wordings and twisted them to mean things that don't make sense

@emenel so like i mentioned there like vaguely gesturing to tons of cryptographic handshakes or some shit. i have a fuller sketch of some of them. but this is pouzin, in 1976, describing basically the above, without reference to anything except node relationships

Indeed, neither VC's nor DG's can carry within a
single packet messages longer than the maximum
length of the data field (this is a tautology). Therefore, oversized messages are fragmented into > pieces the size of a data field and sent as separate > DG's.
At the destination, DG's are reassembled into a copy
of the original message. Duplicates, if any, are discarded ; missing DG's will be retransmitted if acknowledgment conventions have been established with the sender.

the ability to model the network explicitly and represent trust relationships is i think why i independently arrived at this methodology

@emenel basically like. being evil does reduce the adversary's ability to do metacognition. but unfortunately we have to assume there is an evil NSA team that does all this and works very hard so people can't do this

but also cryptography works no matter how smart someone is. and also intelligence is fake

but defining these categories of anonymity attacks will take a while. i have a kind of hope that it's "basically cryptographic measures" (e.g. timing attacks, where there is some practical precedent for e.g. not leaking identity key), and the identity of the message and the sender is just.....part of the ciphertext

@emenel @haskal i still think he sounds like me when i don't have a concrete use case for this part though

Another difference is that while authentication can happen at the key exchange level, and the derived shared symmetric key can be used with STREAM as age does, signatures need to be necessarily computed over the whole message. This sets us back on making the format seekable and streamable: either we make an expensive asymmetric signature for every chunk, or we get fancy with signed Merkle trees, which anyway get us a streamable format only either in the encryption or in the decryption direction. (Or, like discussed above, we just stick a signature at the end and release unverified plaintext at decryption time, causing countless vulnerabilities.)

particularly this part

This sets us back on making the format seekable and streamable

@emenel @haskal oh!! i figured it out lmao

he is literally trying to solve a made up problem the exact same way ziv and lempel took an optimal solution for known-length re-seekable files and said yeah what if we told ourselves we didn't know anything and in fact we refuse to know anything

@emenel @haskal lmao he's so funny

We made it a good UNIX tool, working on pipes

sir i do build tools that is literally THE problem i know of 3 individuals working on incl me. none of us have solved it we just like ponder it

One thing we decided is that we’d not include signing support. Signing introduces a whole dimension of complexity to the UX

hmmmm shit (1) he's right except (2) key management is an interesting framing and indicates his tool is doing too much in a different way.

ok here i wouldn't say "too much" necessarily. but like. "key management" is a really high-level task

i do worry that "only curve25519" (fuck djb) could introduce unexpected assumptions elsewhere that aren't tested. but modifying the type of key is not the way to test them. and it's actually pretty sick to have:

• gen key (+entropy [effect])
• calculate dh key agreement (two keypairs, but only unique per pair--basically for ephemeral only)

• generate symmetric key w salt (+entropy [effect])

  • this is actually not so trivial. i wanna say signal uses aes-256-gcm i'll check rn
  • this is not quite a primitive then but it is something that can be encapsulated w double ratchet

• soooooo what about cases that don't support a session-like context?

the docstring for the single struct in aes_ctr.rs:

yes, i can see that

literally what

this is not the appropriate use of displaydoc fuckboys