Show threadd@nny disc@ mc²Mar 21

@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

Show threadd@nny disc@ mc²Mar 21
@emenel i also found i reimplemented a large portion of GLR parsing by masaru tomita as a subproblem of my parallel parsing approach (separate project) i would say it's almost the same but the parallel perspective is more natural to me. i don't think there is exactly one correct answer ever but it's a good sign to have arrived at the same spot
Show threadd@nny disc@ mc²Mar 21
@emenel so what that network would achieve would be anonymity in a sense that is quantifiable and directly meaningful to users
Show threadd@nny disc@ mc²Mar 21
@emenel "quantifiable" to me is not "a number popped out". i mean "it resists this category of attack up to this boundary". which is.........an engineering guarantee. like a bridge
Show threadd@nny disc@ mc²Mar 21
@emenel i don't think "uptime" is a meaningful metric btw. not in the terms i think of here. "uptime" is not defined in terms that support inference
Show threadd@nny disc@ mc²Mar 21
@emenel you can imagine e.g. a uniform distribution of laser pulses, 10% of which are reliably observed to be deflected by cosmic rays. that's "uptime"
Show threadd@nny disc@ mc²Mar 21
@emenel i don't think it's well-formed to imagine uptime works that way for like. a server. "nine nines" or however many nines that is.......great followup question to ask: "are we assuming a uniform distribution?"
Show threadd@nny disc@ mc²Mar 21
@emenel the request-response process is not effectively instantaneous in most useful network calls, especially if they're variable-length, and if they invoke backend work. googlers are the worst at measuring anything. kinda sad when they post their nature papers like aw that's cute this is enrichment for people who have never written a document for someone to read
Show threadd@nny disc@ mc²Mar 21
@emenel if each node in the paths chosen to ferry your datagrams performs a queueing process and has a ~standard way to respond "i have the datagram you assigned identifier X to" or "idk" or "give me more time" (i have a set of responses in my sketch), then you are not performing turing complete work per input
Show threadd@nny disc@ mc²Mar 21
@emenel and actually you still have multiple other ratios that matter more directly. the ratio of datagrams dropped across a node for one (which, btw, may not be problematic if the node indicates an expected drop ratio)
Show threadd@nny disc@ mc²Mar 21
@emenel "drop ratio" is a hilarious concept but this is where it does kinda matter to define "information theoretic" (in the sense of: in terms of indistinguishability) results that link back to whatever becomes visible to [piano sound] the global passive adversary
Show threadd@nny disc@ mc²Mar 21

@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

Show threadd@nny disc@ mc²Mar 21
@emenel that is as far as i'm aware how you bootstrap anonymity without any cryptography. oh! and last thing on this point
Show threadd@nny disc@ mc²Mar 21
@emenel this is a google cryptographer who is very annoying and has bad opinions but he coauthored with isis lovecruft and his crypto is good https://words.filippo.io/age-authentication/#authentication-vs-signing oooh wait did he update this page
age and Authenticated Encryption

age currently only provides confidentiality. We look at how a couple small tweaks can introduce authentication, when you'd need it, and how it is different from signing.

Show threadd@nny disc@ mc²Mar 21
@emenel wait now that i learned about tree hashing and blake* i understand more of this post @haskal
Show threadd@nny disc@ mc²Mar 21

@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

Show threadd@nny disc@ mc²Mar 21

@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

Show threadd@nny disc@ mc²Mar 21

@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

Show threadd@nny disc@ mc²Mar 21

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

Show threadd@nny disc@ mc²Mar 21
and "no signatures" means "asymmetric crypto can't use half its special attacks"
Show threadd@nny disc@ mc²Mar 21

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?

Show threadd@nny disc@ mc²Mar 21
shit they have cbc ctr gcm.......if they don't describe at length which is used where................that's unfortunate
Show threadd@nny disc@ mc²Mar 21

the docstring for the single struct in aes_ctr.rs:

/// A wrapper around [`ctr::Ctr32BE`] that uses a smaller nonce and supports an initial counter.
pub struct Aes256Ctr32(ctr::Ctr32BE<Aes256>);

yes, i can see that

Show threadd@nny disc@ mc²Mar 21
a damn shame
Show threadd@nny disc@ mc²Mar 21

literally what

#[derive(displaydoc::Display, thiserror::Error, Debug)]
pub enum Error {
/// "unknown {0} algorithm {1}"
UnknownAlgorithm(&'static str, String),
/// invalid key size
InvalidKeySize,
/// invalid nonce size
InvalidNonceSize,
/// invalid input size
InvalidInputSize,
/// invalid authentication tag
InvalidTag,
}

this is not the appropriate use of displaydoc fuckboys

Show threadd@nny disc@ mc²Mar 21
they're not even using thiserror. just impl error::Error. how is this real
Show threadd@nny disc@ mc²Mar 21

(1) completely unrelated to the SPQR fuckboys
(2) 2021????
(3) fuckboy #2 "adding support for username links"
https://github.com/signalapp/libsignal/commit/e50bec648fed7d6f87648c2c7937a9eeda3841b3

COMPLETELY half-assed

Adding support for username links · signalapp/libsignal@e50bec6

Home to the Signal Protocol as well as other cryptographic primitives which make Signal possible. - Adding support for username links · signalapp/libsignal@e50bec6

GitHub
Show threadd@nny disc@ mc²Mar 21
impl fmt::Display for Error {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
match self {
Error::UnknownAlgorithm(typ, named) => write!(f, "unknown {} algorithm {}", typ, named),
Error::InvalidKeySize => write!(f, "invalid key size"),
Error::InvalidNonceSize => write!(f, "invalid nonce size"),
Error::InvalidInputSize => write!(f, "invalid input size"),
Error::InvalidTag => write!(f, "invalid authentication tag"),
Error::InvalidState => write!(f, "invalid object state"),
}
}
}

this is actually much better for a !!!!cryptographic!!!!! error!!!!!

completely did not change the messages, or cases, just fucking removed Clone/Eq/PartialEq which sure that's not a correctness issue but why? why?

Show threadd@nny disc@ mc²Mar 21
#[derive(Debug, displaydoc::Display, thiserror::Error)]
pub enum DecryptionError {
/// The key or IV is the wrong length.
BadKeyOrIv,
/// These cases should not be distinguished; message corruption can cause either problem.
BadCiphertext(&'static str),
}

brb distinguishing your cases

Show threadd@nny disc@ mc²Mar 21

bro says i know. i know what to do

signal-crypto = { path = "../crypto" }

our problem? too much crypto.......not enough signal crypto

same code

Show threadd@nny disc@ mc²Mar 21

i would not accept this at all for any professional work

i would have given my undergrad students maybe a B if it passes all the tests and i gave them the context for them to solve

if it was a junior eng i would totally req to pair and it would be cool as hell and i would learn what kinds of criteria they were familiar with / assuming judged upon

Show threadd@nny disc@ mc²Mar 21
how do you add new protobufs in the same fucking commit
Show threadd@nny disc@ mc²Mar 21
ok so at least main doesn't duplicate deps and uses cargo's (intentionally-broken) "workspace" feature
Show threadd@nny disc@ mc²Mar 21
so that's progress. wait i'm gonna check blame
Show threadd@nny disc@ mc²Mar 21
the king
Show threadd@nny disc@ mc²Mar 21
senpai
Show threadd@nny disc@ mc²Mar 21
my hero jrose-signal who taught me for free
Show threadd@nny disc@ mc²Mar 21

i forgot i had an email to send about checksums but then i found fuckboy #1 at it again https://github.com/signalapp/libsignal/commit/8fcc30278c518306a9471d0ddb496b9a5e722dc6

who changes cbindgen.toml like that. who does that

Add AES-256-GCM implementation · signalapp/libsignal@8fcc302

Along with sub-components AES-256-CTR

GitHub
Show threadd@nny disc@ mc²Mar 21

Specializing this for exactly == 16 results in much better codegen

[does not provide codegen, or indicate method to reproduce]

Show threadd@nny disc@ mc²Mar 21
what is "better codegen" to you dude
Show threadd@nny disc@ mc²
yeah i like when i see more eax than ebx cause that's the one i learned first and it's still my favorite
Mar 21 at 11:09pmWeb
Show threadd@nny disc@ mc²Mar 21
idk how x86 works. was it x86? maybe it was some arm shit
Show threadd@nny disc@ mc²Mar 21
i fail to see how "AES-256-GCM" involves implementing a hash by hand when it's the first implementation?
Show threadd@nny disc@ mc²Mar 21
const AES_BLOCK_SIZE: usize = 16;
const PAR_BLOCKS: usize = 8;
const NONCE_SIZE: usize = AES_BLOCK_SIZE - 4;
const PAD_SIZE: usize = PAR_BLOCKS * AES_BLOCK_SIZE;

pub struct Aes256Ctr32 {
aes256: Aes256,
ctr: [u8; PAD_SIZE],
pad: [u8; PAD_SIZE],
pad_offset: usize,
}

i was gonna say "oh maybe he's C-brained" but no you can still do sizeof(arr) in C

Show threadd@nny disc@ mc²Mar 21
oh omg there's another good eng doing good changes
Show threadd@nny disc@ mc²Mar 21
that's 2
Show threadd@nny disc@ mc²Mar 21
they have a numerical advantage over the cryptographer
Show threadd@nny disc@ mc²Mar 21
who literally acts like i'm not gonna read his 60-page paper and puts everything at the end? like a meme? like in a movie?
Show threadd@nny disc@ mc²Mar 21
if anyone knows any practical applications of adversarial randomness i have a great prank
Show threadd@nny disc@ mc²Mar 21
christ https://eprint.iacr.org/2020/148.pdf poettering jumpscare. this is the paper that afaict describes adversarial randomness
Show threadd@nny disc@ mc²Mar 21
and it appears to describe adversarial randomness as like the specific thing that ratcheting key protocols are resistant to?
Show threadd@nny disc@ mc²Mar 21
if that's true this cryptographer whose benchmarks were completely fabricated owes me tomorrow's lunch money too
Show threadd@nny disc@ mc²Mar 21

they're describing this so generically as if it's theoretical and new

Practical Relevance of Randomness Manipulation
In addition to exposures of locally stored state secrets, randomness for generat-
ing (new) secrets is often considered vulnerable. This is motivated by numerous
attacks in practice against randomness sources (e.g., [11]), randomness genera-
tors (e.g., [23,7]), or exposures of random coins (e.g., [22]). Most theoretic ap-
proaches try to model this threat by allowing an adversary to reveal attacked
random coins of a protocol execution (as it was also conducted in related work
on ratcheting). This, however, assumes that the attacked protocol honestly and
uniformly samples its random coins (either from a high-entropy source or using
a random oracle) and that these coins are only afterwards leaked to the attacker.
In contrast, practically relevant attacks against bad randomness generators or
low-entropy sources (e.g., [11,23,7]) change the distribution from which random
coins are sampled. Consequently, this threat is only covered by a security model if
considered adversaries are also allowed to influence the execution’s (distribution
of) random coins. Thus, it is important to consider randomness manipulation
(instead of reveal), if attacks against randomness are regarded practically rele-
vant.

and i mean it is i think since this paper described it

Show threadd@nny disc@ mc²Mar 21

Examples for
countermeasures are replacing bad randomness generators via software updates

simply sudo pacman -S openssl

Show threadd@nny disc@ mc²Mar 21

Please note our distinction between key agreement and ratcheted key exchange protocols.

oh i am so fucking ready for this i am RIVETED

Show threadd@nny disc@ mc²Mar 21
the distinction they noted........yes, it is one that i identified above
Show threadd@nny disc@ mc²Mar 21

While the security provided by Signal is sufficient in most real-world scenarios,

this is the START of the sentence

we focus in this work on the theoretic analysis of the (optimally secure) primitive ratcheting with respect to its instantiability by smaller building
blocks.

Show threadd@nny disc@ mc²Mar 21
@haskal detected another good cryptographer.......makes sense they would be more difficult to find
Show threadd@nny disc@ mc²Mar 21
wow oops lmao there's no way active adversarial input with intent to deanonymize could be analogous to adversarial randomness..................
Show threadd@nny disc@ mc²Mar 21
i think it's not quite a proof
Show threadd@nny disc@ mc²Mar 21
my favorite "not quite a proof" in the entire world is that "two stacks are turing-complete because you can put them back-to-back and generate the turing tape"