Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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?


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.


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.


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 :)


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?


> 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.


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.


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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: