Hacker News Reader

Comment by jpitz | Hacker News Reader

Or a hard drive shell with a Raspberry PI inside doing the equivalent of piping out /dev/random to the interface.

If it's encrypted it will probably end up in blob storage, which is low cost. If you want to hit them where it hurts, generate tons of fake text (stored as emails, documents, texts, etc.) with GPT-3 to clog up their elasticsearch server and/or NLP classifiers.

Dude,

I get the joke, but an Internet trained bit of code, like GPT-3, isn't what you want writing text files all over your drive.

You'd probably end up on 43 watch lists, and thrown in jail for having time travel child porn, featuring Katie Sagel and Trump in the 60s.

If everybody gets on the list then it doesn't do them as much good. Maybe it is time to become Sparticus.

That works fine until GPT-3 generates inadvertently generates a bunch of incriminating evidence!

Looking forward to the first gpt-3 version of 'it was the best of times, it was the blurst of times'.

Give me six sentences written by the most honest of men...

This made my day hahahaha. How long do you reckon it would take for someone to catch on?

If you encrypt it, presumably they'll try to store it just in case they can decrypt it later. At lest that's what the NSA does.

If you have a good rng it will be indistinguishable from encrypted data. In fact the more uniform the seemingly more cunning.

Be sure to put he proper headers on the data so it self identifies as an encrypted file.

That reminds me of some story I read back in the 90s about some famous hackers (I think the ones who testified to Congress from MIT).

One of them knew their apartment was going to be raided by the FBI so they left a suitcase full of encrypted cassette tapes in there for the FBI to salivate over.

After finally decrypting the first one, I believe it was just static noise :)

> After finally decrypting the first one, I believe it was just static noise :)

That sound fishy, was there any metadata to confirm it has been decrypted? That's the thing with encryption, it's just math, it won't "fail" anything if you got the wrong key, you'll just get random data back.

I hoped, HOPED, this story would end with a link to YouTube where a man in a trenchcoat performs a strange dance while lip-syncing to very concerning lyrics about a man that would never give her up, never let her down...

Yes, I earned the downvotes, have at it.

Anyway this made me want to read Cryptonomicon for the 5th time and gift it to some younguns.

Hehe... wish I had a link for you, I went digging around the internet with some serious Google fu and didn't turn up much. The MIT guys were l0pht, but I couldn't find any stories linked to them.

The original story was in a 200 ish page library book I rented in 2004 or so, and I imagine the publishing of that book was in the early to mid 90s based on the tech and artwork involved :) It was at Half Hollow Hills public library, which has since been demolished!

Same people behind the eponymous cracks from the 90’s warez scene?

Random data is indistinguishable from encrypted data, modulo attached metadata.

If done properly encrypted data looks like random data. That means that if you have a Raspberry Pi pumping out random data (no need for encryption), they'll probably just store it thinking it's top-secret encrypted data that they'll decrypt later.

There is the likelihood that most encryption applications would put a header of some kind on the encrypted blob.

For example, PGP, PKZip, OpenSSL, and age all do this with encrypted files. I'm not sure I can think of a user-oriented encryption application that doesn't. Disk encryption also definitely does (although in TrueCrypt volumes the header is encrypted and not recognizable as such, so TrueCrypt is an exception, probably deliberately).

Crypto primitives in programming languages don't, and NaCl crypto secretboxes don't (they just start with the nonce!), so I guess if you were calling the NaCl secretbox encryptor by hand to encrypt your files, they wouldn't have any header.

For maximum effect you'd want to use something like RSA-1024 which is "just" weak enough that they will take a wack at it, but also strong enough that they'll expend tens or hundreds of thousands of dollars worth of compute attacking it. If you use something "strong" like RSA-4096, they probably won't bother even taking a look at it.

How could they tell? Doesn't encrypted data all look the same?

The ciphertext looks the same, but the file doesn't, since it typically has metadata about what type of encryption is used in plain-text.

Now I'm curious, because I've spent the past little while looking at file encryption headers, whether there's an example where the RSA modulus size is explicitly going to be part of the file header. I guess you could tell even if it was presented as a blob (inside a structured header) because it would be padded to a size that was equal to the length of the modulus...

You don't need to muck around with encryption headers for this. Just install gpg, generate a RSA-1024 key pair, and use the public key to encrypt a rickroll video or something.

Often it will be stored with plaintext metadata.

All symmetrically encrypted data looks the same, but almost all encrypted wire formats and encrypted file formats contain some header information. In particular, GPG / OpenPGP encrypted files will contain a header with the public key's hash. Any investigator with more than a day's experience would check the same device for keyrings and check if any of the public or private keys in the keyrings match any of the messages.

It takes a lot of effort to make all of the metadata also not have distinguishable patterns. See DJB's "Elligator" papers for all of the work that goes into designing elliptic curves for this purpose.

It's really a pain to have a full protocol that looks like white noise even if the attacker has millions of message exchanges to look at. I designed a protocol like that about 20 years ago, using the Station-to-Station protocol with the largest 4096-bit safe prime as the DH modulus. I couldn't use the semantically secure version of DH, because in that case, the first 4096 bits exchanged each way would always be a quadratic residue. The modulus needed to be just under a power of 256, so that even with billions of samples, it wouldn't be surprising that none of them were between the modulus and the maximum N-byte integer. For the individual messages within the stream, I needed to encrypt the message length headers, etc., etc. Even with this white noise-looking protocol, I'm pretty sure the pattern of packet sizes used by TCP to encapsulate the stream would give away the protocol being used. It just really increased the amount of analysis a filtering firewall would need, and increased the false positive rate of attempts to block the protocol. These days, TLS is so common and the pain caused by blindly dropping all TLS connections is so great, that you're probably best off either tunnelling your hidden protocol through TLS, or else making your protocol look like a TLS handshake with common parameters.

With a Raspberry Pi generating random stuff, there's no reason why it can't emulate a drive of infinite capacity.

Infinite drive space you say? Eat your heart out Stacker.

https://en.wikipedia.org/wiki/Stac_Electronics

All it has to do is show two subdirectories for any subdirectory that you enter. It doesn't ever have to return a file. Also, it can be slow.

US law enforcement has such a great sense of humor afterall...

You don't need an RPI to do that, the drives have their own SOC and firmware

Reply on news.ycombinator.com