7 ms·

I recall an interview with William Binney where he suggested simply rearranging your message's payload at the protocol level would be enough to thwart automated

by rl3 10y ago

I recall an interview with William Binney where he suggested simply rearranging your message's payload at the protocol level would be enough to thwart automated analysis. It would require human attention, which is ultimately finite. The trade-off there is that it might draw unwanted attention. Such an approach may be more suited for use inside of a message already encrypted using standard means. It's worth noting that if there's no network interception angle, the NSA can easily penetrate all but the most hardened systems should they be so inclined.

pandler 10y ago
> 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?
- hackermailman 10y ago
  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.
  - dom0 10y ago
    > 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.
    - kakarot 10y ago
      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.
      - nickthemagicman 10y ago
        Bad example but his point is overall pretty solid imo.
        fapjacks 10y ago
        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.
        dmfdmf 10y ago
        <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.
- mSparks 10y ago
  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.
  - loup-vaillant 10y ago
    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 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.
    - mSparks 10y ago
      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.
    - dtech 10y ago
      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-key-sizes-be-smaller-than-rsa-keys-for-similar-security https://crypto.stackexchange.com/questions/13249/why-can-ecc...
    - cesarb 10y ago
Zilroy 10y ago
Binney is suggesting the proper approach - safe manual customizations that require manual cryptanalyzis, which is not scalable. If only few % of users start to roll out their own custom crypto, not stronger than ROT-13, that would completely overwhelm the interception industry, including the state-level players. There is no automated tool that can cryptanalyze in real time someone's naive but unique idea what crypto should be. In other words, this is shifting the paradigm where few high priests of the open source crypto design few key components for billions to use, and cryptanalysis has to deal with only few problems which are eventually automated, to the problem where tens of thousands of brains construct their own weird crypto which has to be manually cryptanalysed. Cryptanalyzers would need to employ millions to achieve this. Feel free to do this on top of the blessed crypto stacks.
- schoen 10y ago
  > There is no automated tool that can cryptanalyze in real time someone's naive but unique idea what crypto should be. This might depend on how big the possibility space is. For example, you could imagine someone making a similar argument about transformations to passwords (like adding digits or punctuation, writing words backwords, changing letters to symbols that resemble them visually, and so on). A lot of people have independently come up with these transformations and correctly reasoned that they expand the space of possible passwords and add uncertainty (entropy) for someone trying to guess a password, especially if they're used in an inconsistent rather than systematic manner. Still, password crackers have had great success explicitly enumerating this possibility space and brute forcing against it, basically since each transformation that people are particularly likely to think of only adds a relatively small amount of uncertainty, on the scale of the overall password cracking problem. This was already recognized at the time of Alec Muffet's Crack program (which let you use manually-specified transformation rules to expand your password-guessing dictionary), and attackers' heuristics and databases have only gotten more powerful since then. It's also discussed in the Diceware xkcd https://www.xkcd.com/936/ https://www.xkcd.com/936/ Here Randall argues that the substitutions added about 11 bits of entropy, plus "a few more bits" because of uncertainty about which ones were used. That wasn't enough to defeat realistic adversaries in this context. I'm concerned that a lot of text obfuscation methods that people would think of will fall into this category and perhaps provide only a handful of bits of additional entropy; for example, they might use familiar encodings that are well-known to puzzlers (like Morse code, binary, semaphore, the NATO alphabet), they might write things backwards or in a customized order at an n-gram level, they might use what is effectively a simple substitution cipher, and a few other possibilities. I don't think it would be difficult to try an extremely large number of these possibilities, combined with sophisticated statistical tests for plaintext. I bet versions of these analysis tools that work pretty well were developed decades ago. Computers are very fast and combinations of brute force and statistical analysis are very powerful. To be clear, I wouldn't discourage people from doing this (on top of standard communications security methods), and I would agree that it might sometimes provide a benefit. But I would discourage people from assuming that their homegrown text obfuscator is giving more benefit than using "Tr0ub4dor&3" instead of "troubador" as their password (a non-zero benefit, yet an inadequate benefit against sophisticated adversaries). Maybe there's a way to change that picture, but I guess it would involve having people spend a lot more time studying and thinking about it, in the hope of greatly expanding the space of possible encoding transformations that they're capable of thinking up. And then you still have to be careful of statistical analysis. We might think we're very clever by inventing a new transliteration of our language into a script that was never before used to transcribe it, and then a statistical tool may still successfully analyze that transliteration as a simple substitution cipher and break it automatically!

by rl3 10y ago

pandler 10y ago

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

hackermailman 10y ago
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.
- dom0 10y ago
  > 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.
  - kakarot 10y ago
    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.
    - nickthemagicman 10y ago
      Bad example but his point is overall pretty solid imo.
      - fapjacks 10y ago
        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.
        dmfdmf 10y ago
        <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.
mSparks 10y ago
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.
- loup-vaillant 10y ago
  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 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.
  - mSparks 10y ago
    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.
  - dtech 10y ago
    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-key-sizes-be-smaller-than-rsa-keys-for-similar-security https://crypto.stackexchange.com/questions/13249/why-can-ecc...
  - cesarb 10y ago

Zilroy 10y ago

Binney is suggesting the proper approach - safe manual customizations that require manual cryptanalyzis, which is not scalable. If only few % of users start to roll out their own custom crypto, not stronger than ROT-13, that would completely overwhelm the interception industry, including the state-level players. There is no automated tool that can cryptanalyze in real time someone's naive but unique idea what crypto should be. In other words, this is shifting the paradigm where few high priests of the open source crypto design few key components for billions to use, and cryptanalysis has to deal with only few problems which are eventually automated, to the problem where tens of thousands of brains construct their own weird crypto which has to be manually cryptanalysed. Cryptanalyzers would need to employ millions to achieve this. Feel free to do this on top of the blessed crypto stacks.

schoen 10y ago
> There is no automated tool that can cryptanalyze in real time someone's naive but unique idea what crypto should be. This might depend on how big the possibility space is. For example, you could imagine someone making a similar argument about transformations to passwords (like adding digits or punctuation, writing words backwords, changing letters to symbols that resemble them visually, and so on). A lot of people have independently come up with these transformations and correctly reasoned that they expand the space of possible passwords and add uncertainty (entropy) for someone trying to guess a password, especially if they're used in an inconsistent rather than systematic manner. Still, password crackers have had great success explicitly enumerating this possibility space and brute forcing against it, basically since each transformation that people are particularly likely to think of only adds a relatively small amount of uncertainty, on the scale of the overall password cracking problem. This was already recognized at the time of Alec Muffet's Crack program (which let you use manually-specified transformation rules to expand your password-guessing dictionary), and attackers' heuristics and databases have only gotten more powerful since then. It's also discussed in the Diceware xkcd https://www.xkcd.com/936/ https://www.xkcd.com/936/ Here Randall argues that the substitutions added about 11 bits of entropy, plus "a few more bits" because of uncertainty about which ones were used. That wasn't enough to defeat realistic adversaries in this context. I'm concerned that a lot of text obfuscation methods that people would think of will fall into this category and perhaps provide only a handful of bits of additional entropy; for example, they might use familiar encodings that are well-known to puzzlers (like Morse code, binary, semaphore, the NATO alphabet), they might write things backwards or in a customized order at an n-gram level, they might use what is effectively a simple substitution cipher, and a few other possibilities. I don't think it would be difficult to try an extremely large number of these possibilities, combined with sophisticated statistical tests for plaintext. I bet versions of these analysis tools that work pretty well were developed decades ago. Computers are very fast and combinations of brute force and statistical analysis are very powerful. To be clear, I wouldn't discourage people from doing this (on top of standard communications security methods), and I would agree that it might sometimes provide a benefit. But I would discourage people from assuming that their homegrown text obfuscator is giving more benefit than using "Tr0ub4dor&3" instead of "troubador" as their password (a non-zero benefit, yet an inadequate benefit against sophisticated adversaries). Maybe there's a way to change that picture, but I guess it would involve having people spend a lot more time studying and thinking about it, in the hope of greatly expanding the space of possible encoding transformations that they're capable of thinking up. And then you still have to be careful of statistical analysis. We might think we're very clever by inventing a new transliteration of our language into a script that was never before used to transcribe it, and then a statistical tool may still successfully analyze that transliteration as a simple substitution cipher and break it automatically!