What is Nostr?
waxwing /
npub1vad…nuu7
2025-04-15 13:17:05
in reply to nevent1q…url3

waxwing on Nostr: Have you read my "tlstweet" gist? Linked below if you haven't. What you're saying ...

Have you read my "tlstweet" gist? Linked below if you haven't. What you're saying here is a close cousin to that. The idea there is that there is randomness that is transmitted on point-to-point connections which can be exploited to transfer encrypted data (because that's also pseudorandom). The assumption behind what I'm saying at the start of this thread is that we want something that cannot be statistically suspicious and so immediately flagged by the censor. If we have data that is *supposed* to be random, but is sent as broadcast and not point-to-point, that can be the ideal, not because encrypted data has to be pseudorandom, but because it gives us maximal entropy to embed messages. If I'm restricted to only human-plausible text I have *way* less entropy to work with, so (and this is where I'm not sure) it might not be possible to do f(x, y) = z where *all* of x, y and z are totally (or in case of z, partially) human readable text, *and* have z be slow to compute (so the censor can't just immediately flag y).

So back to your idea, it's definitely plausible (and I think has probably been done) to embed encrypted data in low order bits of images and then also embed keys, I think it's a practical idea though very low bitrate of course; in terms of message-to-bandwidth ratio with an actually aggressive censor, I'm not sure (most toy demos of e.g. "bitcoin tx in jpeg" don't consider this. It may fool the human eye but not a program, etc.)

https://gist.github.com/AdamISZ/83a17befd84992a7ad74
Author Public Key
npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7