Announcement

Collapse
No announcement yet.

The Linux Kernel's Speck Death Sentence Finally Being Carried Out

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    beautiful.
    so the main argument for Open Source isn't even considered valid by its developers. if the code (which is open after all!) contains bugs they should be fixed (or even better- not mainlined till it's fine).
    Will they purge linux of NSA's SELinux too (which wouldn't be that bad, AppArmor FTW!)?

    Comment


    • #12
      Originally posted by szymon_g View Post
      beautiful.
      so the main argument for Open Source isn't even considered valid by its developers. if the code (which is open after all!) contains bugs they should be fixed (or even better- not mainlined till it's fine).
      Will they purge linux of NSA's SELinux too (which wouldn't be that bad, AppArmor FTW!)?
      WTF are you even on about? Cipher analysis and review takes place on crypto lists, not in the kernel tree.

      Comment


      • #13
        i assume this happened because nobody cared to maintain this code.

        otherwise this is an example of unjust bias and "all nsa code is evil" prejudice.

        Comment


        • #14
          Originally posted by meir View Post
          Wow... They'll accept code from Apple, but when it comes to the US Government, that's where the line is drawn..
          To be fair, Apple might not be RedHat but they do have a history of contributing to open source and they've also proven time and again that they try very hard not to comply with US government warrants. Much more so than other companies.

          On another note, I wonder if anyone ever discovered an actual vulnerability in Speck or people just automatically freaked out that it's developed by the NSA.

          Comment


          • #15
            Originally posted by msotirov View Post
            To be fair, Apple might not be RedHat but they do have a history of contributing to open source and they've also proven time and again that they try very hard not to comply with US government warrants. Much more so than other companies.

            On another note, I wonder if anyone ever discovered an actual vulnerability in Speck or people just automatically freaked out that it's developed by the NSA.
            Can you blame them? The NSA is a US spy agency and linux is a global phenomenon.

            Comment


            • #16
              Originally posted by garegin View Post
              “The question was if there were backdoors in the mathematical design of the cryptography.”

              isnt that also in the source code?
              Originally posted by szymon_g View Post
              beautiful.
              so the main argument for Open Source isn't even considered valid by its developers. if the code (which is open after all!) contains bugs they should be fixed (or even better- not mainlined till it's fine).
              Will they purge linux of NSA's SELinux too (which wouldn't be that bad, AppArmor FTW!)?
              No the source code didn't contain bugs or backdoors, it correctly implemented the Speck crypto. And if a cipher is flawed then you can't just fix it, it needs to be redesigned.

              People don't say curl is flawed because http traffic is vulnerable to a MITM attack, it is the http protocol that is flawed not curl's implementation of it. Just like here it was the Speck crypto that was believed to be flawed, not the implementation.

              Speck wasn't meant to be a totally secure encryption like AES, it was meant to be 'good enough' for low powered devices, but doubts were raised about whether it was even 'good enough'. In the end Google (who were the only people who wanted to use it) decided that there were better options and dropped their support for Speck, so it is now being removed.

              Comment


              • #17
                AFAIK, for curl to implement HTTP it has to use the http libraries. In the same sense, the design of the crypto math has to be in the source code for the program to do the encryption.
                So yeah. If HTTP has a design flaw, they you could catch it in its software implementation.
                as an example, when SSLv3 had a design flaw, it could be traced in all v3 implementations like openssl. There is “external” math outside of the software.
                Last edited by garegin; 25 October 2018, 12:16 AM.

                Comment


                • #18
                  garegin I know your reasoning may sound appealing to you atm, but crypto algorithms area special breed of software.

                  Often the strength of crypto algorithm is assessed based on its math properties - it's usual to say some algorithm is safe enough, because breaking it would mean finding a way to quickly solve a mathematical problem which is presumed or proven to be extremely computationally hard.

                  Now, if such relation does not exist or is not proven, there is a possibility that this algorithm is practically useless.

                  At that point there is really little you can do with implementation code, because you had a flawed math model to start with, and no reasonable amount of tinkering around it will provide a "fix". You basically need to create a new model, hence a new cipher.

                  No one can fix MD5 hash, for instance. It's weaknesses are known. The remedy was to develop new hash methods with better properties - fixing MD5 code is futile.

                  Comment

                  Working...
                  X