Announcement

Collapse
No announcement yet.

Marvell Announces New OCTEON TX2 + OCTEON Fusion CPUs

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

  • #11
    Cryptography doesn't necessarily have anything to do with security, so a co-processor whose function was to accelerate cryptographic algorithms (e.g. hashing or asymmetric crypto), would be best called a 'cryptographic co-processor'. But yeah; I can see why a name with as many syllables as that wouldn't be popular with 'the suits'.

    Comment


    • #12
      Originally posted by cybertraveler View Post
      Cryptography doesn't necessarily have anything to do with security
      I'm not sure what other use cases you have in mind as that's more or less the only thing it is useful for. Keeping some information outside the reach of enemies (encryption), or make sure some enemy isn't tampering with your message (signatures). That's security.
      The cards and accelerators are used to run VPN applications and HTTPS in 99.99% of the cases.

      Using cryptographic algorithms for integrity checks (catching natural communication issues or bitrot) is possible in many cases but it is usually overkill. For example btrfs is using the same old CRC32C algorithm for its checksumming (it's designed to allow addition of other algorithms easily, but so far no others were added), and using anything significantly harder than that would hammer performance hard, for debatable reasons. https://kdave.github.io/selecting-hash-for-btrfs/
      Last edited by starshipeleven; 05 March 2020, 07:05 AM.

      Comment


      • #13
        Originally posted by starshipeleven View Post
        I'm not sure what other use cases you have in mind as that's more or less the only thing it is useful for. Keeping some information outside the reach of enemies (encryption), or make sure some enemy isn't tampering with your message (signatures). That's security.
        The cards and accelerators are used to run VPN applications and HTTPS in 99.99% of the cases.

        Using cryptographic algorithms for integrity checks (catching natural communication issues or bitrot) is possible in many cases but it is usually overkill. For example btrfs is using the same old CRC32C algorithm for its checksumming (it's designed to allow addition of other algorithms easily, but so far no others were added), and using anything significantly harder than that would hammer performance hard, for debatable reasons. https://kdave.github.io/selecting-hash-for-btrfs/
        You mentioned hashing for integrity checks already which is a popular and perfectly valid use case. This is partly why md5sums are popular today for integrity checks, but not security. md5 is cryptographically broken, but still very practical for many integrity check purposes.

        Also: hashes are used for hashing values for many types of database. Those hashes then serve as a lookup key.

        Encryption is sometimes used as an obfuscation tool, not for security. e.g. if you don't want deep packet inspection, network hardware to mess with / throttle your protocol you can encrypt it (maybe even using a shared, pre-shared-key/secret). This can increase the reliability of your connection (not security). I think some Bittorrent clients do this.

        "Proof of Work" algorithms are one last example of a potentially, non-security application of cryptography. They can be used for rate limiting coin emission in a crypto currency (among other uses) or anti-spam in a messaging system.

        Cryptogrpahy is heavily used for security but definitely has many other applications. The above are just the ones I could think of off the top of my head.

        The CRC32 comment you made was interesting. TY.

        Comment


        • #14
          Originally posted by cybertraveler View Post
          You mentioned hashing for integrity checks already which is a popular and perfectly valid use case. This is partly why md5sums are popular today for integrity checks, but not security. md5 is cryptographically broken, but still very practical for many integrity check purposes.
          Not really, for anything where you need performance even md5 is horrendously slow.

          I mean OK you can use SHA256 to validate your linux iso downloads, but this does not make this a usecase where crypto is necessary.

          If you want to do serious integrity checking and CRC32r isn't enough for your tastes you should use algorithms that were designed for integrity checking from the start like SpookyHash, Adler32, Fletcher or whatever. That's what filesystems and SnapRAID use https://www.snapraid.it/compare

          Also: hashes are used for hashing values for many types of database. Those hashes then serve as a lookup key.
          I don't know what this is. I mean I know about lookup keys but I'm not sure where in it is hashing involved.

          Encryption is sometimes used as an obfuscation tool, not for security. e.g. if you don't want deep packet inspection, network hardware to mess with / throttle your protocol you can encrypt it (maybe even using a shared, pre-shared-key/secret). This can increase the reliability of your connection (not security). I think some Bittorrent clients do this.
          This falls within the case of "not showing the message to your enemy" case as above and it's a form of VPN, definitely security.

          "Proof of Work" algorithms are one last example of a potentially, non-security application of cryptography. They can be used for rate limiting coin emission in a crypto currency (among other uses) or anti-spam in a messaging system.
          Eh, yes and no.

          Proof of work is basically "waste of computational power" for the sake of limiting the ability to reproduce something. Yes crypto algos have been used as "first generation", but that's just because they were easily available.

          Most crypto algos are pretty crappy "proof of work" algos as you can get ASICs or FPGAs to do it pretty fast at a relatively cheap price, even if it's "custom" enough that you can't just repurpose commercial "security coprocessor" hardware. And this is bad as unless you have a very large userbase it's easy for a malicious party to just hijack your blockchain by investing in powerful hardware.

          Afaik decent "second gen" proof of work algos for cryptocurrency for example are focusing on other things like RAM speed or bandwith or whatever else where the "waste of computational power" is not possible (or very difficult) to brute force with ASICs

          Comment


          • #15
            Thanks, for the reply. Re, this:

            Originally posted by starshipeleven View Post
            This falls within the case of "not showing the message to your enemy" case as above and it's a form of VPN, definitely security.
            In the case I mentioned, the enemy can obtain the message if they want to, it's just prohibitively expensive for them to do it on a mass scale in an automated fashion. So it doesn't hide the message, it just makes it so existing DPI hardware can't decode it and thus the ISP can't easily tag the connection and do something annoying with it.

            Comment


            • #16
              Originally posted by cybertraveler View Post
              In the case I mentioned, the enemy can obtain the message if they want to, it's just prohibitively expensive for them to do it on a mass scale in an automated fashion. So it doesn't hide the message, it just makes it so existing DPI hardware can't decode it and thus the ISP can't easily tag the connection and do something annoying with it.
              I'm not sure how is this different from VPN and "end-to-end encryption".

              Because that's what they do. They take the packet contents and encrypt it so it can be intercepted but not read. I mean, it's still a packet like any other, there is no way around this, network infrastructure expects headers and other standards to route it correctly and you can't change this.

              The only way to read the contents is decrypt them with the key, sniff the key somehow by exploiting vulnerabilities in the protocol (assuming they do that at all, decent VPNs don't), or outright break the encryption (for example if you are using crap-grade VPN like old Windows default's pptp that was broken for decades but then again it is ancient).

              So if you are just using a crappy encryption algorithm (why would you though? the traffic for a p2p filesharing or whatever isn't so huge that most PCs can't handle it and x86 has hardware acceleration for serious encryption algorithms anyway) it's still technically a form of VPN or end-to-end encryption. Lower security, but still security. You don't want them to look at your message.

              For example, that's how Netflix managed to finally screw people using VPNs in a more or less definitive way.
              They just have some guy checking the static IP list of commercial VPN providers and made a manual blacklist for them (i.e. all packages that come from those IPs are blocked). Because it's not a secret, at most you need an account in every VPN provider around and you have all their server's IP addresses (as that's required to connect to them as part of the service).

              Chinese don't do that for their "great firewall of china" because of other reasons (it's better to tag and control and milk money from a few VPN users than block all and have them come up with something you really can't control at all), but they really could too if they wanted.
              Last edited by starshipeleven; 06 March 2020, 07:23 AM.

              Comment


              • #17
                The secret key is shared and there is nothing stopping an ISP from buying more expensive DPI hardware that can actually find the key and decrypt the packets. So the encryption is entirely about obfuscation which is computationally and human-labor expensive to decrypt/deobfuscate.

                So, considering the above, an ISP (or something/one with tentacles inside of an ISP) might be interested in hardware which makes use of an efficient cryptographic accelerator for non-security purposes.

                Comment


                • #18
                  Originally posted by cybertraveler View Post
                  The secret key is shared and there is nothing stopping an ISP from buying more expensive DPI hardware that can actually find the key and decrypt the packets.
                  Now, let's look at the only thing you might be referring to as anything else is either a proxy or a VPN:

                  https://en.wikipedia.org/wiki/BitTor...col_encryption

                  The key is shared in a relatively secure way but it is using a weak insecure cypher. But the specification was written in 2006, when the cypher used was still deemed secure (apart from a known attack that this specification does mitigate against already), and then never updated since.

                  This is just a case of outdated shit VPN or "end-to-end encryption" that was then mostly abandoned (not updated to be secure again) because it was a PITA to do this already and people can use a normal VPN provider to have perfect security regardless, not a case of "let's just use encryption for obfuscation".

                  So, considering the above, an ISP (or something/one with tentacles inside of an ISP) might be interested in hardware which makes use of an efficient cryptographic accelerator for non-security purposes.
                  Cracking encryption is a completely different job than what crypto accelerators do.

                  Crypto accelerators process the algorithm "the right way" by taking the data, the key and doing the math required to encrypt or decrypt the data, end of the story.

                  Cracking an algorithm is (nearly always) a completely different operation that they are not usually able to do.

                  To crack stuff you are either talking about putting up a GPU farm, programming a FPGA to act as a "poor man accelerator" (that is usually still better than a GPU), or designing a specific ASIC accelerator to do this cracking job.

                  Comment

                  Working...
                  X