13 ms·

Thanks for that rabbit hole! See also: https://github.com/mmcc1/crystalline https://github.com/mmcc1/crystalline http://maldr0id.blogspot.com/2015/05/crystall

by jascii 7y ago

Thanks for that rabbit hole! See also: https://github.com/mmcc1/crystalline https://github.com/mmcc1/crystalline http://maldr0id.blogspot.com/2015/05/crystalline-cipher-and-cryptography.html http://maldr0id.blogspot.com/2015/05/crystalline-cipher-and-... The authors inability to take any criticism is stunning, sometimes I wonder if a fragile ego isn't one of the greatest barriers to cyber security..

asudosandwich 7y ago
What if he’s not meant to be read in good faith?
thethirdone 7y ago
From the github README: > Designed to be as secure as a one-time pad, without a weakness due to the use of repeating keys, That immediately shows that the person writing it doesn't know cryptography. You simply can't get the security of one-time pad without having a key the size of the data, and if you do, just use it as the pad.
- cryptonector 7y ago
  And you can't reuse the keys in a one-time pad system.
  - jascii 7y ago
    Lol, I always wondered what the "one-time" bit meant ;)
  - klingonopera 7y ago
    Nitpick: You can, but you shouldn't.
    - jascii 7y ago
      Nitpick: the moment you do, it stops being a one-time pad.
      - klingonopera 7y ago
        I've always wondered if the assumption, they're never using the same one twice, would suffice to practically always use the same one then (assuming data-length never changes).
        alecbenzer 7y ago
        Not sure what you're asking? If you use the same key over and over again, then you're using the same key much more than just twice. The idea of a one-time-pad is that you're basically just randomly flipping the bits of your input, which means the output of an OTP cipher is indistinguishable from random data. If you're using the same key multiple times though, then the output of the cipher (considered over time) won't be random, and you'll be able to detect patterns from the original input in the cipher output (e.g., the shape of an image, frequency of certain letters).
        klingonopera 7y ago
        The output is always random, regardless how often the key has been used. The thing is, if you know the same key has been used a second time, then yes, having both outputs (can? will? must? could?) helps to acquire the key. But how do you know they're using the same one? Or how are you sure, they're not? All you have, are two pieces of random data.
        alecbenzer 7y ago
        > The output is always random, regardless how often the key has been used. The output of any _one_ use of the pad is, yes, but the point is to consider all of the data that an attacker may have. If you re-use the key multiple times, then the entirety of the cipher texts an attacker has is not random. (See also: https://xkcd.com/221/ https://xkcd.com/221/) > But how do you know they're using the same one? Or how are you sure, they're not? You'll be able to tell because you'll see patterns in the data: https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb....
    - klyrs 7y ago
      If yor rot13 your OTP the second time around, it's probably fine. In the same way that turning your underwear inside out is probably fine. As long as nobody sniffs...
    - cryptonector 7y ago
      "Can" as in "you could possibly do it, yeah", and "shouldn't" as in "really, really, REALLY shouldn't". The Venona cable decrypts were made possible by one-time pad reuse.
      - klingonopera 7y ago
        I'm not sure, definitely not if you use XOR-OTP, not so sure about additive-OTP, see my reply here[0] for reasons. Would like to know, if my assessment on additive OTP is correct, if anyone knows? EDIT: I mean, of course you still shouldn't, but where the XOR catastrophically fails after just a single reuse, the additive one should be more robust, even with reuse. The Venona Decrypts were additive-OTP, I postulate, the decryption rate would've probably been higher with XOR-OTP. [0]: https://news.ycombinator.com/item?id=22448966 https://news.ycombinator.com/item?id=22448966
        numpad0 7y ago
        I thought the notion of OTP is that there is absolutely nothing to decode, prove or disprove ciphertext? Like if ciphertext is "supersecret" then it feels like plaintext can't be more obvious and OTP must be "00000000000", but there's nothing anywhere to logically/mathematically support it. OTP could be something else and plaintext could be "hackernews" or "ycombinato". In reality a simple XOR with a random sequence preserve enough entropy of data that I've heard you could make out voices if used on media, so payloads must be scrambled, but that's not recovery, only a guess. ANY reuse breaks that notion and make it not an OTP cryptography.
- Someone 7y ago
  There’s also the claim > Crystalline employs information loss as the basis of its security. If encryption loses information, there’s no way decryption can bring it back. In the extreme def encrypt(s): return “(TOP SECRET)” is totally secure, but also totally useless.
  - segfaultbuserr 7y ago
    Not useless. This is, in fact, the most widely used encryption algorithm in declassified government documents! /joke
  - khazhoux 7y ago
    Not totally useless. You just need the dual: def decrypt("(TOP SECRET)"): return s
    - alexeiz 7y ago
      I know how to fix it. Blockchain!
  - dreamcompiler 7y ago
    I noticed this too. One of two things is going on: a. The author cannot decrypt it either, unless he's cheating somehow, or b. It's not really losing information and the author is lying.
- infinity0 7y ago
  >> Designed to be as secure as a one-time pad, > That immediately shows that the person writing it doesn't know cryptography. You simply can't get the security of one-time pad [..] Talking about a one-time pad at all in the context of making something actually secure for internet usage, shows that the talker doesn't know about cryptography. A one-time pad having "perfect security" is only true in the context of a particular security model that doesn't generally hold true on the internet - one where the adversary cannot change the ciphertext whilst it is in transit. Under a more realistic security model, we need a message authentication code or some other equivalent, to protect against adversaries changing the ciphertext. It's a well-known theorem of modern cryptography that in fact if you don't have secure authentication under this model, then you cannot achieve secure privacy. In other words, your ciphertext has to be bigger than the plaintext for security on the internet. (There is in fact a one-time-pad equivalent for MACs where your key is the length of the plaintext and the ciphertext ends up being several multiple times the length of the plaintext, but crackpots when making security arguments about "one-time pads" generally aren't referring to this and aren't even aware of the existence of this. It's a relatively unknown construction and nobody really talks about it in the context of serious modern cryptography.)
  - scolby33 7y ago
    What is the MAC-like construction for an OTP cipher?
    - fdupress 7y ago
      One-time MACs... The most widely used constructions are based on polynomials: GHASH (from GCM) and Poly1305.
cryptonector 7y ago
This happens with some regularity in the crypto scene. Someone comes up with a cipher and they think it must be awesome! because they came up with it. Not being cryptographers, these ciphers always fall quickly, then the authors get defensive. I want a doll with Alan Turing's likeness that says "cryptography is hard" when you pull the cord.
- jascii 7y ago
  Cryptography is hard enough when using proven algorithms..
  - Gibbon1 7y ago
    I remember on an old crypto mailing list some lowly PHP programmer asking if instead of a grab bag of primitives there was some library where he could just encrypt/decrypt a random object. Without having to build a Frankenstein thing out of random cryptographic parts. Everyone peed on him and he never came back. The poor sap was right though. The proven algorithms tend to fail catastrophically when used or implemented incorrectly.
    - larzang 7y ago
      Ironically now PHP is one of the few high-level languages doing this right, with built-in libsodium support and an excellent idiot-proof library available in Halite on top of that.
      - jjeaff 7y ago
        Agreed. And it even has a global you can use for the cipher that is updated along with the php version.
- teddyh 7y ago
  “Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break.” — Bruce Schneier https://www.schneier.com/blog/archives/2011/04/schneiers_law.html https://www.schneier.com/blog/archives/2011/04/schneiers_law...
jiggawatts 7y ago
The author reminds of some religious people I've had debates with in the past. They would make some fundamentally flawed argument, get shot down, and so they would move on to other arguments, which is not great but valid. But then, later, I'd see them making the exact same argument to someone else. To people like this, arguing is like punching. If you punch someone and they get up, they're a "tough opponent". That doesn't mean that punching is ineffective on other people. They just don't understand at their core that once an argument is shown to be false, it can never be reused. Their mind just doesn't work this way. They think "Well, left-hook didn't work on this guy, but maybe it'll work in that guy" or "This guy didn't fall for this argument, but maybe that guy will." It's deeply dishonest, but I'm not convinced they're even aware of this. So, just from a cursory look at his code, the glaring problems I see are: 1) It'll crash if you feed it more than 256MB because of the way the C# BitArray class works. He's also using 32-bit ints in several places that have similar issues. These are implementation details, but it just goes to show how thoughtless the "reference implementation" is. 2) Similarly, the reference implementation copies the entire data into the BitArrary (and then back into a byte array) for each "round". This is spectacularly inefficient. He never mentions throughput in terms of MB/s/GHz or any such thing. I wonder why... 3) It's not a stream cipher. You need to encrypt the entire file. Again, he could come up with some sort of streaming version by feeding in the last few KB of the previous encrypted chunk into the next chunk, but he hasn't. As the long history of various streaming ciphers have shown, this is actually a hard problem to solve efficiently and securely. This is why AES-GCM is the hot new thing: it's both. 4) If either the key or salt values are all 0s then the encryption does nothing. AES for comparison will still encrypt your data with some level of security even if the IV initialisation is not perfectly random or skipped. 5) He's calculating the offsets as an "int" from a byte multiplied by a byte. Hence the maximum shift is 65536 positions. This is just big enough to exceed L1 data cache on most platforms, but have a high hit ratio. Whether you hit the L1 cache or not depends on the Key & IV values, so this is a recipe for timing-based side-channel attacks. Constant-time cyphers are basically mandatory these days... 6) Related to the above: The bit shifts are only in an 8KB window, but the byte shifts are in an 64KB window. I wonder if there's some interaction here where this might make some keys insecure. 7) Despite this windowing, the default "protocol" wraps around the end of the file to the beginning using a modulo the data.Length, so it can't be used as a streaming cipher. To do so, he'd have to introduce a breaking change. 8) The encryption is defined in terms of bit-by-bit and byte-by-byte long-range operations, so there's basically no hope of ever making this efficient. E.g.: with SIMD or similar many-bytes-at-a-time instruction sets. The "state" that would have to be kept in CPU registers is over 64KB, so this is just never, ever, EVER going to compete with something like AES-NI. I could go on, but I'm wasting my time. This is wasting everyone's time. The author clearly has no interest in producing something that is secure and usable. He's just enjoying the arguments. He's even posted some of the feedback on his GitHub, proudly showing off the debates he's felt he's won. Don't feed this troll.
andrewflnr 7y ago
> sometimes I wonder if a fragile ego isn't one of the greatest barriers to cyber security.. If you include the fragile egos of sysadmins and executives who refuse to fix their systems, then yes, absolutely.
userbinator 7y ago
On the other hand, I feel like the elitist, alienating "don't even try to learn, just obey us" attitude of much of the cryptography/security community could also be making the situation worse. I mean, a key-and-data-dependent permutation is how a lot of ciphers work; that's not a fundamentally flawed idea. The details of the implementation are a different matter, however.
- chapium 7y ago
  Fortunately most books don't have an opinion about who is reading them.
- infinity0 7y ago
  That's like saying "being a vehicle is how a lot of cars work"; the reasons on why the cipher is flawed are a bit more specific than that. As for the elitist arrogance, whilst I'm sure these exist in other security-related interactions across the world, the interaction that's the subject of this thread involves plenty of polite comments that - point out author's lack of background knowledge - refer to short-cut theorems that help evaluate a cipher, implying the author should learn about these theorems - explicitly tell the author to learn about these theorems In response to this, the very first reply the author gives is "It almost sounds like you have had your soul crushed by bureaucracy over the years and have lost all passion for this field. I hope that's not true." Yeah, however much "arrogant" you interpret the security people in this thread to be, it's only fair to interpret the OP (Mark McCarron) to be 2-3x as arrogant.
- lima 7y ago
  They did in fact encourage him to learn and even pointed him to various entry-level resources and mailing lists.
- bob1029 7y ago
  I am honestly very triggered by any tone of elitism in the sphere of intellectual or professional pursuits. It's not just in tech - just try googling 'DIY HVAC Repair'. Now, I don't advocate partaking in activities which are legitimately dangerous without training and certification (e.g. charging an HVAC system with freon or operating a crane), but when all you are trying to do is replace a contactor in your HVAC system and you get a wall of "DIY is not allowed here" when asking basic questions, it really puts some hate into your soul. Cryptographers give me the exact same sensation with their 'no DIY' rhetoric. At the end of the day for me, it mostly boils down to some ulterior agenda which seeks to keep competition or perceived threats to the incumbents' control at bay. Does the NSA have a vested interest in most technology workers being able to competently roll their own encryption schemes? From my very jaded political perspective, I would say absolutely not. It arguably makes their mission exponentially harder if they have to deal with novel approaches to securing communications. They would probably prefer everyone just use ECC with their hand-selected curve parameters.
lilSebastian 7y ago
> The authors inability to take any criticism is stunning Unfortunately I find that this is all too common.

by jascii 7y ago

asudosandwich 7y ago

What if he’s not meant to be read in good faith?

thethirdone 7y ago

From the github README: > Designed to be as secure as a one-time pad, without a weakness due to the use of repeating keys, That immediately shows that the person writing it doesn't know cryptography. You simply can't get the security of one-time pad without having a key the size of the data, and if you do, just use it as the pad.

cryptonector 7y ago
And you can't reuse the keys in a one-time pad system.
- jascii 7y ago
  Lol, I always wondered what the "one-time" bit meant ;)
- klingonopera 7y ago
  Nitpick: You can, but you shouldn't.
  - jascii 7y ago
    Nitpick: the moment you do, it stops being a one-time pad.
    - klingonopera 7y ago
      I've always wondered if the assumption, they're never using the same one twice, would suffice to practically always use the same one then (assuming data-length never changes).
      - alecbenzer 7y ago
        Not sure what you're asking? If you use the same key over and over again, then you're using the same key much more than just twice. The idea of a one-time-pad is that you're basically just randomly flipping the bits of your input, which means the output of an OTP cipher is indistinguishable from random data. If you're using the same key multiple times though, then the output of the cipher (considered over time) won't be random, and you'll be able to detect patterns from the original input in the cipher output (e.g., the shape of an image, frequency of certain letters).
        klingonopera 7y ago
        The output is always random, regardless how often the key has been used. The thing is, if you know the same key has been used a second time, then yes, having both outputs (can? will? must? could?) helps to acquire the key. But how do you know they're using the same one? Or how are you sure, they're not? All you have, are two pieces of random data.
        alecbenzer 7y ago
        > The output is always random, regardless how often the key has been used. The output of any _one_ use of the pad is, yes, but the point is to consider all of the data that an attacker may have. If you re-use the key multiple times, then the entirety of the cipher texts an attacker has is not random. (See also: https://xkcd.com/221/ https://xkcd.com/221/) > But how do you know they're using the same one? Or how are you sure, they're not? You'll be able to tell because you'll see patterns in the data: https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb....
  - klyrs 7y ago
    If yor rot13 your OTP the second time around, it's probably fine. In the same way that turning your underwear inside out is probably fine. As long as nobody sniffs...
  - cryptonector 7y ago
    "Can" as in "you could possibly do it, yeah", and "shouldn't" as in "really, really, REALLY shouldn't". The Venona cable decrypts were made possible by one-time pad reuse.
    - klingonopera 7y ago
      I'm not sure, definitely not if you use XOR-OTP, not so sure about additive-OTP, see my reply here[0] for reasons. Would like to know, if my assessment on additive OTP is correct, if anyone knows? EDIT: I mean, of course you still shouldn't, but where the XOR catastrophically fails after just a single reuse, the additive one should be more robust, even with reuse. The Venona Decrypts were additive-OTP, I postulate, the decryption rate would've probably been higher with XOR-OTP. [0]: https://news.ycombinator.com/item?id=22448966 https://news.ycombinator.com/item?id=22448966
      - numpad0 7y ago
        I thought the notion of OTP is that there is absolutely nothing to decode, prove or disprove ciphertext? Like if ciphertext is "supersecret" then it feels like plaintext can't be more obvious and OTP must be "00000000000", but there's nothing anywhere to logically/mathematically support it. OTP could be something else and plaintext could be "hackernews" or "ycombinato". In reality a simple XOR with a random sequence preserve enough entropy of data that I've heard you could make out voices if used on media, so payloads must be scrambled, but that's not recovery, only a guess. ANY reuse breaks that notion and make it not an OTP cryptography.
Someone 7y ago
There’s also the claim > Crystalline employs information loss as the basis of its security. If encryption loses information, there’s no way decryption can bring it back. In the extreme def encrypt(s): return “(TOP SECRET)” is totally secure, but also totally useless.
- segfaultbuserr 7y ago
  Not useless. This is, in fact, the most widely used encryption algorithm in declassified government documents! /joke
- khazhoux 7y ago
  Not totally useless. You just need the dual: def decrypt("(TOP SECRET)"): return s
  - alexeiz 7y ago
    I know how to fix it. Blockchain!
- dreamcompiler 7y ago
  I noticed this too. One of two things is going on: a. The author cannot decrypt it either, unless he's cheating somehow, or b. It's not really losing information and the author is lying.
infinity0 7y ago
>> Designed to be as secure as a one-time pad, > That immediately shows that the person writing it doesn't know cryptography. You simply can't get the security of one-time pad [..] Talking about a one-time pad at all in the context of making something actually secure for internet usage, shows that the talker doesn't know about cryptography. A one-time pad having "perfect security" is only true in the context of a particular security model that doesn't generally hold true on the internet - one where the adversary cannot change the ciphertext whilst it is in transit. Under a more realistic security model, we need a message authentication code or some other equivalent, to protect against adversaries changing the ciphertext. It's a well-known theorem of modern cryptography that in fact if you don't have secure authentication under this model, then you cannot achieve secure privacy. In other words, your ciphertext has to be bigger than the plaintext for security on the internet. (There is in fact a one-time-pad equivalent for MACs where your key is the length of the plaintext and the ciphertext ends up being several multiple times the length of the plaintext, but crackpots when making security arguments about "one-time pads" generally aren't referring to this and aren't even aware of the existence of this. It's a relatively unknown construction and nobody really talks about it in the context of serious modern cryptography.)
- scolby33 7y ago
  What is the MAC-like construction for an OTP cipher?
  - fdupress 7y ago
    One-time MACs... The most widely used constructions are based on polynomials: GHASH (from GCM) and Poly1305.

cryptonector 7y ago

This happens with some regularity in the crypto scene. Someone comes up with a cipher and they think it must be awesome! because they came up with it. Not being cryptographers, these ciphers always fall quickly, then the authors get defensive. I want a doll with Alan Turing's likeness that says "cryptography is hard" when you pull the cord.

jascii 7y ago
Cryptography is hard enough when using proven algorithms..
- Gibbon1 7y ago
  I remember on an old crypto mailing list some lowly PHP programmer asking if instead of a grab bag of primitives there was some library where he could just encrypt/decrypt a random object. Without having to build a Frankenstein thing out of random cryptographic parts. Everyone peed on him and he never came back. The poor sap was right though. The proven algorithms tend to fail catastrophically when used or implemented incorrectly.
  - larzang 7y ago
    Ironically now PHP is one of the few high-level languages doing this right, with built-in libsodium support and an excellent idiot-proof library available in Halite on top of that.
    - jjeaff 7y ago
      Agreed. And it even has a global you can use for the cipher that is updated along with the php version.
teddyh 7y ago
“Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break.” — Bruce Schneier https://www.schneier.com/blog/archives/2011/04/schneiers_law.html https://www.schneier.com/blog/archives/2011/04/schneiers_law...

jiggawatts 7y ago

The author reminds of some religious people I've had debates with in the past. They would make some fundamentally flawed argument, get shot down, and so they would move on to other arguments, which is not great but valid. But then, later, I'd see them making the exact same argument to someone else. To people like this, arguing is like punching. If you punch someone and they get up, they're a "tough opponent". That doesn't mean that punching is ineffective on other people. They just don't understand at their core that once an argument is shown to be false, it can never be reused. Their mind just doesn't work this way. They think "Well, left-hook didn't work on this guy, but maybe it'll work in that guy" or "This guy didn't fall for this argument, but maybe that guy will." It's deeply dishonest, but I'm not convinced they're even aware of this. So, just from a cursory look at his code, the glaring problems I see are: 1) It'll crash if you feed it more than 256MB because of the way the C# BitArray class works. He's also using 32-bit ints in several places that have similar issues. These are implementation details, but it just goes to show how thoughtless the "reference implementation" is. 2) Similarly, the reference implementation copies the entire data into the BitArrary (and then back into a byte array) for each "round". This is spectacularly inefficient. He never mentions throughput in terms of MB/s/GHz or any such thing. I wonder why... 3) It's not a stream cipher. You need to encrypt the entire file. Again, he could come up with some sort of streaming version by feeding in the last few KB of the previous encrypted chunk into the next chunk, but he hasn't. As the long history of various streaming ciphers have shown, this is actually a hard problem to solve efficiently and securely. This is why AES-GCM is the hot new thing: it's both. 4) If either the key or salt values are all 0s then the encryption does nothing. AES for comparison will still encrypt your data with some level of security even if the IV initialisation is not perfectly random or skipped. 5) He's calculating the offsets as an "int" from a byte multiplied by a byte. Hence the maximum shift is 65536 positions. This is just big enough to exceed L1 data cache on most platforms, but have a high hit ratio. Whether you hit the L1 cache or not depends on the Key & IV values, so this is a recipe for timing-based side-channel attacks. Constant-time cyphers are basically mandatory these days... 6) Related to the above: The bit shifts are only in an 8KB window, but the byte shifts are in an 64KB window. I wonder if there's some interaction here where this might make some keys insecure. 7) Despite this windowing, the default "protocol" wraps around the end of the file to the beginning using a modulo the data.Length, so it can't be used as a streaming cipher. To do so, he'd have to introduce a breaking change. 8) The encryption is defined in terms of bit-by-bit and byte-by-byte long-range operations, so there's basically no hope of ever making this efficient. E.g.: with SIMD or similar many-bytes-at-a-time instruction sets. The "state" that would have to be kept in CPU registers is over 64KB, so this is just never, ever, EVER going to compete with something like AES-NI. I could go on, but I'm wasting my time. This is wasting everyone's time. The author clearly has no interest in producing something that is secure and usable. He's just enjoying the arguments. He's even posted some of the feedback on his GitHub, proudly showing off the debates he's felt he's won. Don't feed this troll.

andrewflnr 7y ago

> sometimes I wonder if a fragile ego isn't one of the greatest barriers to cyber security.. If you include the fragile egos of sysadmins and executives who refuse to fix their systems, then yes, absolutely.

userbinator 7y ago

On the other hand, I feel like the elitist, alienating "don't even try to learn, just obey us" attitude of much of the cryptography/security community could also be making the situation worse. I mean, a key-and-data-dependent permutation is how a lot of ciphers work; that's not a fundamentally flawed idea. The details of the implementation are a different matter, however.

chapium 7y ago
Fortunately most books don't have an opinion about who is reading them.
infinity0 7y ago
That's like saying "being a vehicle is how a lot of cars work"; the reasons on why the cipher is flawed are a bit more specific than that. As for the elitist arrogance, whilst I'm sure these exist in other security-related interactions across the world, the interaction that's the subject of this thread involves plenty of polite comments that - point out author's lack of background knowledge - refer to short-cut theorems that help evaluate a cipher, implying the author should learn about these theorems - explicitly tell the author to learn about these theorems In response to this, the very first reply the author gives is "It almost sounds like you have had your soul crushed by bureaucracy over the years and have lost all passion for this field. I hope that's not true." Yeah, however much "arrogant" you interpret the security people in this thread to be, it's only fair to interpret the OP (Mark McCarron) to be 2-3x as arrogant.
lima 7y ago
They did in fact encourage him to learn and even pointed him to various entry-level resources and mailing lists.
bob1029 7y ago
I am honestly very triggered by any tone of elitism in the sphere of intellectual or professional pursuits. It's not just in tech - just try googling 'DIY HVAC Repair'. Now, I don't advocate partaking in activities which are legitimately dangerous without training and certification (e.g. charging an HVAC system with freon or operating a crane), but when all you are trying to do is replace a contactor in your HVAC system and you get a wall of "DIY is not allowed here" when asking basic questions, it really puts some hate into your soul. Cryptographers give me the exact same sensation with their 'no DIY' rhetoric. At the end of the day for me, it mostly boils down to some ulterior agenda which seeks to keep competition or perceived threats to the incumbents' control at bay. Does the NSA have a vested interest in most technology workers being able to competently roll their own encryption schemes? From my very jaded political perspective, I would say absolutely not. It arguably makes their mission exponentially harder if they have to deal with novel approaches to securing communications. They would probably prefer everyone just use ECC with their hand-selected curve parameters.

lilSebastian 7y ago

> The authors inability to take any criticism is stunning Unfortunately I find that this is all too common.