5 ms·

>So I think that as a first step, no-encryption is better than using Speck Yeah so the guy just throws everything out of the window.

bhouston 8y ago
He is only throwing out Speck and saying it is worse than no-encryption.
- emilfihlman 8y ago
  He's throwing out all of his reputation with that claim also. He should not hold any Senior Researcher positions if this message is anything to go by.
  - larkeith 8y ago
    Could you please address and refute his reasoning (probided in the prior paragraph), so as to encourage discussion?
    - drostie 8y ago
      Oh there are so many reasons. The easiest is the adoption problem, the same as hit HTTPS: at least 40% of top websites are still unencrypted even after a massive push from browsers to muscle them into submission; compare to the fact that with no massive push 90% of the ones that do support HTTPS don’t support SSL (they only support TLS, the old standard having severe security flaws). In other words there are concrete numbers to back up the point that when an algorithm is learned to be broken, it is easy to convince panicking folks to upgrade it. But when it simply doesn't exist and hasn't ever, it is harder to convince folks that they need it. Even more to the point, attacks do not exist in isolation and there is no “secure/insecure” dichotomy. You can see this with AES where the AES-256 key schedule is much weaker than the AES-192 key schedule, but the place where this really shines is in related-key attacks, where AES-192 has about twice the bit-strength of AES-256. Does that mean you should switch over? Well, probably not: related key attacks are structurally harder to pull off. The qualitative differences make comparison hard. Probably if the NSA had an exploit for Speck for example, it would take the form of "steal the device running Speck for an hour to get some carefully chosen challenge-response pairs, return it back to the user, budget a day or two of time on the supercomputer to look for patterns in that data, and finally you can recover the key." (I say this in part because it’s hard to hide backdoors in symmetric crypto.) Many applications would be more secure than nothing if that were the only applicable threat model. But even quantitatively, in theory security is not a binary. It's much closer to a dollar amount: here is how much it costs to launch attacks against this system. And $0 on this scale is certainly lower than a serious vulnerability at the $100,000 level. Basically this is a solid argument why you should not roll your own crypto but those arguments are categorically not transferable to crypto whose specifications are known openly and subjects of active cryptanalysis.
      - memory_grep 8y ago
        the ones that do support HTTPS don’t support SSL (they only support TLS, the old standard having severe security flaws) Isn't TLS the successor to SSL?
        tialaramex 8y ago
        Yes, but I think your parent's point is that the sites which enable HTTPS _did_ choose to remove support for known-broken protocols versions, so you've got on the one hand people who cared at all, all doing something vaguely modern and secure, and people who did nothing (plain HTTP), with no security. You can think of TLS 1.0 as essentially SSLv3.1, with TLS 1.1 and TLS 1.2 then as SSLv3.2 and SSLv3.3 And you might think of this as the normal course of any versioned system - tinnier and tinnier changes, except TLS 1.3 (now awaiting publication) is basically completely fresh, it only looks similar on the wire until encryption switches on, in order to maximise compatibility with legacy middleboxes, once it penetrates the middleboxes it's nothing like SSLv3.
1001101 8y ago
Ashur points out the reasoning here just before this statement: 'I would also like to point out that including an algorithm because "it's better than nothing" result in something that is not better-than-nothing, but stands in the way of good solutions.' and 'From the end-user point of view when they get something bundled into Android, they don't know that it was included there as something that is "better than nothing". They think of it as "good enough; endorsed by Android/Google/Linux". What you give them is a false sense of security because they don't know of all the question marks surrounding Speck (both technical and political).' Edit: also some very good comments in there along the lines of 'why not use AES?', and that the problem that Speck is solving might not be with us for very long.
larkeith 8y ago
Out of curiosity, were Speck to be known as vulnerable to key recovery attacks, would you still endorse it as better than no encryption? Personally, I agree with his point - for applications where AES is unsuitable and no encryption is currently in use, it is better to wait for hardware to support AES (or an alternative to Speck to become available) rather than implement an algorithm that may lead to expanded vulnerability of the device via key recovery.
- bostik 8y ago
  Sorry to barge in from the outside, but your question is vaguely specified. > Out of curiosity, were Speck to be known as vulnerable to key recovery attacks, would you still endorse it as better than no encryption? My answer to this would be: "it depends". In this case, it depends on the security margin and just how much easier the key recovery attacks would be compared to brute force. For a cipher with 128-bit key, if the best known attack, after years of careful and aggressive cryptanalysis, required 2^122 work I probably would use it. If the best attack required 2^90 work, I wouldn't use it. After all we are talking about security margins and risk tolerance.
ttsda 8y ago
I believe what he meant by that was that without encryption, you are aware everything you send might be intercepted and read by a third-party, whereas with a flawed encryption algorithm you might send sensitive information under the wrong assumption that it is safe from attack.

bhouston 8y ago

He is only throwing out Speck and saying it is worse than no-encryption.

emilfihlman 8y ago
He's throwing out all of his reputation with that claim also. He should not hold any Senior Researcher positions if this message is anything to go by.
- larkeith 8y ago
  Could you please address and refute his reasoning (probided in the prior paragraph), so as to encourage discussion?
  - drostie 8y ago
    Oh there are so many reasons. The easiest is the adoption problem, the same as hit HTTPS: at least 40% of top websites are still unencrypted even after a massive push from browsers to muscle them into submission; compare to the fact that with no massive push 90% of the ones that do support HTTPS don’t support SSL (they only support TLS, the old standard having severe security flaws). In other words there are concrete numbers to back up the point that when an algorithm is learned to be broken, it is easy to convince panicking folks to upgrade it. But when it simply doesn't exist and hasn't ever, it is harder to convince folks that they need it. Even more to the point, attacks do not exist in isolation and there is no “secure/insecure” dichotomy. You can see this with AES where the AES-256 key schedule is much weaker than the AES-192 key schedule, but the place where this really shines is in related-key attacks, where AES-192 has about twice the bit-strength of AES-256. Does that mean you should switch over? Well, probably not: related key attacks are structurally harder to pull off. The qualitative differences make comparison hard. Probably if the NSA had an exploit for Speck for example, it would take the form of "steal the device running Speck for an hour to get some carefully chosen challenge-response pairs, return it back to the user, budget a day or two of time on the supercomputer to look for patterns in that data, and finally you can recover the key." (I say this in part because it’s hard to hide backdoors in symmetric crypto.) Many applications would be more secure than nothing if that were the only applicable threat model. But even quantitatively, in theory security is not a binary. It's much closer to a dollar amount: here is how much it costs to launch attacks against this system. And $0 on this scale is certainly lower than a serious vulnerability at the $100,000 level. Basically this is a solid argument why you should not roll your own crypto but those arguments are categorically not transferable to crypto whose specifications are known openly and subjects of active cryptanalysis.
    - memory_grep 8y ago
      the ones that do support HTTPS don’t support SSL (they only support TLS, the old standard having severe security flaws) Isn't TLS the successor to SSL?
      - tialaramex 8y ago
        Yes, but I think your parent's point is that the sites which enable HTTPS _did_ choose to remove support for known-broken protocols versions, so you've got on the one hand people who cared at all, all doing something vaguely modern and secure, and people who did nothing (plain HTTP), with no security. You can think of TLS 1.0 as essentially SSLv3.1, with TLS 1.1 and TLS 1.2 then as SSLv3.2 and SSLv3.3 And you might think of this as the normal course of any versioned system - tinnier and tinnier changes, except TLS 1.3 (now awaiting publication) is basically completely fresh, it only looks similar on the wire until encryption switches on, in order to maximise compatibility with legacy middleboxes, once it penetrates the middleboxes it's nothing like SSLv3.

1001101 8y ago

Ashur points out the reasoning here just before this statement: 'I would also like to point out that including an algorithm because "it's better than nothing" result in something that is not better-than-nothing, but stands in the way of good solutions.' and 'From the end-user point of view when they get something bundled into Android, they don't know that it was included there as something that is "better than nothing". They think of it as "good enough; endorsed by Android/Google/Linux". What you give them is a false sense of security because they don't know of all the question marks surrounding Speck (both technical and political).' Edit: also some very good comments in there along the lines of 'why not use AES?', and that the problem that Speck is solving might not be with us for very long.

larkeith 8y ago

Out of curiosity, were Speck to be known as vulnerable to key recovery attacks, would you still endorse it as better than no encryption? Personally, I agree with his point - for applications where AES is unsuitable and no encryption is currently in use, it is better to wait for hardware to support AES (or an alternative to Speck to become available) rather than implement an algorithm that may lead to expanded vulnerability of the device via key recovery.

bostik 8y ago
Sorry to barge in from the outside, but your question is vaguely specified. > Out of curiosity, were Speck to be known as vulnerable to key recovery attacks, would you still endorse it as better than no encryption? My answer to this would be: "it depends". In this case, it depends on the security margin and just how much easier the key recovery attacks would be compared to brute force. For a cipher with 128-bit key, if the best known attack, after years of careful and aggressive cryptanalysis, required 2^122 work I probably would use it. If the best attack required 2^90 work, I wouldn't use it. After all we are talking about security margins and risk tolerance.

ttsda 8y ago

I believe what he meant by that was that without encryption, you are aware everything you send might be intercepted and read by a third-party, whereas with a flawed encryption algorithm you might send sensitive information under the wrong assumption that it is safe from attack.