4 ms·

Ignoring the rhetoric for a second, are there examples of these design decisions being asked about and being dismissed or flat-out not answered? Most of us hav

by tobz 12y ago

Ignoring the rhetoric for a second, are there examples of these design decisions being asked about and being dismissed or flat-out not answered? Most of us have seen the back and forth over generics in Go, including Rob Pike's own blog? post about why Go doesn't have them. With that said, though, I feel like I've also seen a lot of internals-related discussions with good discourse from all sides. Whatever the existing design is or isn't, it doesn't seem fair to go off on such a rampage unless there's some sort of documented example that they are actively trying to avoid simplifying things and really are seeking to fulfill all of the things the author wrote. So... is there any evidence of that?

vorador 12y ago
This is only remotely related, but the golang maintainers have refused to include support for the (insecure, but used on some legacy systems) ECB encryption mode, because it's insecure: http://code.google.com/p/go/issues/detail?id=5597 http://code.google.com/p/go/issues/detail?id=5597 .
- pa7ch 12y ago
  Although they don't have an ECB func, You can trivially implement it from their AES library. I imagine the thinking goes something like, if you don't know enough to write a couple lines to implement ECB, you probably shouldn't be using it. It really doesn't take a deep understanding of crypto understand ECB. ECB is the simplest AES mode, you just encrypt each block of your message using the same key. Here is an image of a penguin encrypted with AES-ECB:http://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg http://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.j... Do you see the problem?
  - georgemcbay 12y ago
    Yeah, this. Didn't realize people actually saw this as an issue worthy of worrying about. The Matasano Crypto Challenges I did way back when were in Go and the ones involving ECB were just done as for loops over the standard library AES Decrypt/Encrypt methods, something like this: for i := 0; i < blockCount; i++ { start := i * blockLength end := start + blockLength aes.Decrypt(decryptBuffer, input[start:end]) output = append(output, decryptBuffer) }
    - richm44 12y ago
      The fact you can still see the penguin is the least of ECBs problems. If you can do an adaptive chosen plain text attack then you can easily retrieve the key when ECB is used.
justin66 12y ago
The most direct answer, which the author only mentions in passing, is gccgo. The author gives vent to the angry voices in his head by attacking the primary go implementation and Rob Pike personally (but ignores the intrinsic merits of the language itself), but gccgo works great.

by tobz 12y ago

vorador 12y ago

This is only remotely related, but the golang maintainers have refused to include support for the (insecure, but used on some legacy systems) ECB encryption mode, because it's insecure: http://code.google.com/p/go/issues/detail?id=5597 http://code.google.com/p/go/issues/detail?id=5597 .

pa7ch 12y ago
Although they don't have an ECB func, You can trivially implement it from their AES library. I imagine the thinking goes something like, if you don't know enough to write a couple lines to implement ECB, you probably shouldn't be using it. It really doesn't take a deep understanding of crypto understand ECB. ECB is the simplest AES mode, you just encrypt each block of your message using the same key. Here is an image of a penguin encrypted with AES-ECB:http://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg http://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.j... Do you see the problem?
- georgemcbay 12y ago
  Yeah, this. Didn't realize people actually saw this as an issue worthy of worrying about. The Matasano Crypto Challenges I did way back when were in Go and the ones involving ECB were just done as for loops over the standard library AES Decrypt/Encrypt methods, something like this: for i := 0; i < blockCount; i++ { start := i * blockLength end := start + blockLength aes.Decrypt(decryptBuffer, input[start:end]) output = append(output, decryptBuffer) }
  - richm44 12y ago
    The fact you can still see the penguin is the least of ECBs problems. If you can do an adaptive chosen plain text attack then you can easily retrieve the key when ECB is used.

justin66 12y ago

The most direct answer, which the author only mentions in passing, is gccgo. The author gives vent to the angry voices in his head by attacking the primary go implementation and Rob Pike personally (but ignores the intrinsic merits of the language itself), but gccgo works great.