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

> rearranging your message's payload at the protocol level

Do you have an example of how you might do that? Something like (real basic example) reversing a json payload?

{"key": {}} becomes {{}: "yek"}

Or is that too simplistic?



I was guessing changing the protocol, like adding or subtracting a few aes rounds to a ssh connection so a standard connection doesn't even speak your protocol and can't connect.

This also reminds me of when somebody here wrote about meeting one of the cryptographers at a con for SHA3 (Blake?) and the guy shrugged off his efforts saying it was all for fun meaning whatever device you have is so completely back doored already either through sabotaged/weakened standards or outright (proprietary microcode) that believing any algorithm can keep a secret from nation state adversaries is laughable.


> believing any algorithm can keep a secret from nation state adversaries is laughable.

Well, yeah, it is.

Defence against (crypto-buzzword) state-level actors (SLAs) doesn't start with gpg and FDE, rather, with operational security, or, even better, not being a worthwhile target in the first place (if your briefcase of secret documents is already on CNN there is no need to infiltrate your stuff beyond gaining assurance that you don't have another briefcase - which is the thing you want to proof as publicly as possible to convince your highly paranoid adversary)

There is that saying "never trust a computer you can't throw out the window". Computers are networked. You're trusting a network of computers, even if you don't use "networked functionality". Can you throw the internet out the window? Probably not! Hence, don't trust computers. People who trust computers to keep their secrets are foolish¹ (Trottel), so just don't.

¹ Notice how governments²³ trust computers to keep their secrets safe, and how admirably and totally that failed. Ask yourself, what wasn't leaked by Snowden? Stuff that wasn't in any computer in the first place!

² Or how celebrities trusted computers to keep their dickpics safe.

³ Or how companies trusted computers to keep their business secrets, well, uh, secret.

To make my point another way: Computers are for disseminating information. If secrecy is more important than dissemination, then don't use a computer.


Umm... I think the number of things not leaked by Snowden far surpasses the number of things leaked by him, and the things he didn't leak weren't not leaked because they weren't on a computer... they just weren't in the files he accessed.


Bad example but his point is overall pretty solid imo.


I think the NSA definitely seemed to hit a point where they calmed down. At first there was a palpable sense of "O NOE" as the NSA scrambled to discover what exactly had been stolen. And then just as suddenly, it seemed to go away. I don't think the really shocking stuff was exfil'ed by Snowden. I won't speculate what wasn't revealed, except that I think it's telling that the NSA has been asking for the ability to award high-level mathematics commendations to its workers without explaining why they deserve the award. Not much in Snowden's documents seem to fit that particular bill. The NSA isn't going to want to award the Fields Medal to someone for 0day exploits, weakening crypto infrastructure, or friggin USB hacks.


<At first there was a palpable sense of "O NOE" as the NSA scrambled to discover what exactly had been stolen. And then just as suddenly, it seemed to go away.>

I think a big part of them not commenting on the issue was that they didn't know what Snowden had and they got caught in a number of lies early on.


nsa shill:everyone should use curve25519 hacker news:downvote to hell anyone who disagrees

that off my chest.

"protocol level" is the order of the bits. for example the octets in the tcp protocol.

"rearranging the payload" in this case is moving around those octets. and while of course it would work, is a bit simplistic. (so yeah, yek not far off)

the "Best" solution imho is to chain more than one cipher together. "like truecrypt does". for example, if you are using a pre shared key, use that key to encrypt the dhe with a symmetric cipher and a nonce. or some other non trivial obfuscation.

but the point is valid, even simple obfuscation requires human intervention, which breaks mass surveillance en mass.


Nobody is secure against their home country government, which has the power to both:

-- Mount black bag attacks on your premises. -- Snoop the networks of internet service providers.

On the other hand, most or all of the following are true of my keys-to-the-kingdom email account (the one from which most other passwords can be reset):

-- It is very unlikely to be hacked by any information guesses of my password, social engineering of my "secret question" information, shenanigans with my mobile phone, etc.

-- It is with a provider who seems less likely to get hacked than even Yahoo.

-- It has security that would be hard to brute force.

-- It has a unique password that I don't use on other, more vulnerable accounts.

Even so, I assume that all my communications are available to the US government, at least by after-the-fact subpoena if not actually real time.


->Nobody is secure against their home country government, which has the power to both: -- Mount black bag attacks on your premises. -- Snoop the networks of internet service providers.

Indeed, not even our governments are safe from the government. like when they forced backdoors in juniper routers, then used juniper routers in government facilities. resulting in widespread compromise of most if not all government facilities and the loss of billions of dollars r&d advantage.

At least they put tons of effort into securing the voting system and didnt let a russian stooge get declared leader of the free world tho. so there is still some hope.

for us tho. encrypted at rest, and intrusion detection generally good practice.


Something is nagging me for quite some time. DJB invented curve25519, which is advertised to offer 128 bits security. On the other hand, DJB also said 128 bits are not enough for symmetric crypto. https://cr.yp.to/snuffle/bruteforce-20050425.pdf

This makes me a bit uneasy: would a parallel brute force search would be much more difficult for elliptic curves than it would for symmetric cyphers? Why? By the way, a similar problem arises with poly1305. I'm missing something.


Well, curve25519 uses 256-bit keys (actually, a few bits less than 256). The parallel brute force search should take time similar to that of a 256-bit symmetric cipher.

The reason curve25519 has a security level of only 128 bits is that ECDLP takes time proportional to the square root, so half the number of bits (https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Ke...).

As for poly1305, it actually uses not one, but two separate 128-bit keys. The authentication tag computed using the first key is encrypted with the second key. For a brute force search, it should be as hard as breaking something with a single key of around 256 bits.


Afaik breaking a 128-bit ECC key does not require brute-forcing 2^128 keys but rather computing 1 difficult problem on a 128-bit input.

Breaking e.g. AES key of n bits requires you to try 2^n combinations, but the actual computation per key is very fast.

[1] https://crypto.stackexchange.com/questions/13249/why-can-ecc...


I think what you are missing is the huge investment the "bad guys" have put into getting people to believe insecure communications are in fact secure.


A batch attack on 128 bit symmetric lowers the total cost to below 2^128 computations to successfully decrypt messages. The cost approximately follows the birthday paradox math, and thus becomes cheaper at a slightly faster than linear rate given a higher volume of ciphertexts.

A batch attack on asymmetric ECDSA like curve25519 costs MORE than 2^128, it just grows logarithmicly instead of linearly.

That's why.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: