6 ms·

Lightweight Cryptography

throw0101a 5y ago
The NSA developed some light-weight algorithms that were submitted to the ISO, but they were initially rejected due to lingering suspicions: * https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers-iso https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers... * https://en.wikipedia.org/wiki/Simon_(cipher) https://en.wikipedia.org/wiki/Simon_(cipher) * https://en.wikipedia.org/wiki/Speck_(cipher) https://en.wikipedia.org/wiki/Speck_(cipher) The ISO went with PRESENT and CLEFIA for ISO/IEC 29192 ("Information technology - Security techniques - Lightweight cryptography"): * https://en.wikipedia.org/wiki/PRESENT https://en.wikipedia.org/wiki/PRESENT * https://en.wikipedia.org/wiki/CLEFIA https://en.wikipedia.org/wiki/CLEFIA A bit of a history of that episode: * https://link.springer.com/chapter/10.1007/978-3-030-10591-4_4 https://link.springer.com/chapter/10.1007/978-3-030-10591-4_... S&S were eventually accepted for ISO 29167.
- rdpintqogeogsaa 5y ago
  SPECK is a really attractive design for software implementation. The key schedule and the round function are the same, it's an ARX design that lends itself to naturally constant-time implementation. If the design is free of fault and it gets thrown out because of its origin and admittedly questionable public analysis statements, that's rather unfortunate. Alas, it's hard to trust given the backstory, but on the other hand the author(s) might be relying entirely on cryptanalytic techniques and results they're not able to publish for whatever reason.
  - GTP 5y ago
    >but on the other hand the author(s) might be relying entirely on cryptanalytic techniques and results they're not able to publish for whatever reason But this is bad, the best way to ensure that some cryptanalytic technique works is to publish it so every cryptographer in the world can review it.
    - espadrine 5y ago
      > the best way to ensure that some cryptanalytic technique works is to publish it so every cryptographer in the world can review it The best way to ensure that a design is sound, is to publish it, but that is not true of cryptanalysis techniques. They are generally tied to a mathematical proof, so they can be quite confident of their correctness. A design, on the other hand, has an unknown number of ways in which it can fail. Also, historically, secret cryptanalyses have proved invaluable in warfare; the most famous examples are the techniques used for Enigma, Lorenz SZ42, and the “Purple” Type B Cipher Machine, which allowed reading various crucial messages from the Nazi and Imperial Japan during WWII; had the techniques been published, the ciphers would have been improved. There is still a very good reason to not like that situation: first, commercial information is much more sizeable and is arguably much more sensitive nowadays, as warfare is shifting to the weakening of the enemies’ economy (look at Russia turning a blind eye or more on the groups behind the Colonial Pipeline hack). Second, the government’s cryptanalysis effort is financed by the people, so it would be reasonable for them to receive its fruits.
      - GTP 5y ago
        another reason to not like it: if there are out there ciphers which could be broken with such hypotetic tecnique we miss the chance to move away from them/design ciphers that are robust against that tecnique. which is exactly what secret services usually want to have a cryptographic advantage over enemies, but at the same time they endanger everyone else, as also the enemy coukd independently discover that tecnique and start using that against e.g. businesses.
    - MertsA 5y ago
      The NSA will never do that as it would be tipping their hand about whatever novel technique they reveal. In the past the NSA actually did provide some constants that went into DES and people were suspicious as the constants weren't randomly chosen. Later on it came out that differential cryptanalysis would have broken the original constants but the NSA provided ones were chosen to thwart this. They clearly knew about it well ahead of it being discovered in academia. Then you have the NSA's shady dealings around Dual_EC_DRBG where there was speculation that this might be similar to when the NSA secured DES against publicly unknown advanced cryptanalytic attacks. Of course for Dual_EC_DRBG that wasn't the case, it was a malicious backdoor, nothing more. The question comes down to "Is this a repeat of DES or Dual_EC_DRBG?" and the NSA has poisoned the well with their previous attack on cryptography standards.
  - JoachimS 5y ago
    But both algorithms are confidentiality only, not AE. And they need a lot of rounds to provide any real security.
28194608 5y ago
Who won the encryption against quantum computer?
- hannob 5y ago
  You likely mean the nist post quantum competition, which is about public key encryption and signatures. The answer is noone yet, it's still running. Here's the list of proposals currently in the competition: https://csrc.nist.gov/Projects/post-quantum-cryptography/round-3-submissions https://csrc.nist.gov/Projects/post-quantum-cryptography/rou...
- 0xdeadb00f 5y ago
  These are symmetric ciphers. So.. All of them?
  - JoachimS 5y ago
    One thing though is that many lightweight block ciphers only have 128 bit keys. So in a PQ context, they will only provide 64 bit strength. Thus might be ok for short term secrets. But if you are building devices (IoT, SCADA) with long lifetimes, you may need to add a key derivation, key exchange scheme.
marcosdumay 5y ago
Last time I checked, all the computers were growing powerful and crypto was relevant neither for latency nor for power consumption on any device capable of joining a network. It helps that one of the largest factors on choosing crypto algorithms is speed on both general purpose and specialized hardware. So, count me in the group of people that don't understand why the NIST is doing this. Will they trade any security guarantee for speed? If so, nobody should ever use one of those algorithms. If not, whatever algorithm wins here would also win a new round of general purpose crypto contest.
- wmf 5y ago
  Check out the case of storage encryption in smartwatches and very cheap phones. The CPUs do not have AES instructions and doing software AES makes the watch noticeably sluggish. https://lwn.net/ml/linux-crypto/20180806223300.113891-1-ebiggers@kernel.org/ https://lwn.net/ml/linux-crypto/20180806223300.113891-1-ebig...
  - marcosdumay 5y ago
    The question is, are you ok with the encryption being breakable if it makes your watch faster? Personally, if I'm ok with the encryption being breakable, I'm also ok with not using any encryption at all. I can't imagine a scenario where I would want weak encryption. Anyway, the way to solve that problem is to get a CPU with AES instructions.
    - wmf 5y ago
      That tradeoff doesn't exist. No one is proposing weak or breakable encryption. Even the fastest "lightweight" finalists provide full 128-bit security.
      - marcosdumay 5y ago
        If they have 128-bit security, what is the difference between that and a normal contest?
joelbondurant 5y ago
NEVER trust algorithms from extortion sector low life degenerate thugs.
ur-whale 5y ago
Can someone point to a resource describing why various candidates got rejected in round 1 and round 2? Any comments on the decisions or was it just voting without explaining?
- rdpintqogeogsaa 5y ago
  See NISTIR 8369, available from [0], p. 40 et seq. in particular. [0] https://csrc.nist.gov/publications/detail/nistir/8369/final https://csrc.nist.gov/publications/detail/nistir/8369/final
nemo1618 5y ago
One nice thing about lightweight crypto is that it's easy to port. Implementing ASCON in Go was pretty fun and only took an hour or two: https://github.com/lukechampine/ascon/blob/master/ascon.go https://github.com/lukechampine/ascon/blob/master/ascon.go (Obviously it wouldn't make a ton of sense to use Go if you're resource-constrained, but having a library is worthwhile for compatibility reasons regardless.)
JoachimS 5y ago
One really good thing with the finalist algorithms is that they all provide authenticated encryption. For many IoT systems, authentication and integrity protection is way more important than condidentiality. Many older lightweight algorithms (or AES) for that matter requires adding either an authentication mode, or another primitive (a hash function used in HMAC for example) I believe that has led to a problematic proliferation of only having confidentiality protection in too many IoT systems deployed. These candidates makes it easier for developers to add the security properties their system actually needs.

The NSA developed some light-weight algorithms that were submitted to the ISO, but they were initially rejected due to lingering suspicions: * https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers-iso https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers... * https://en.wikipedia.org/wiki/Simon_(cipher) https://en.wikipedia.org/wiki/Simon_(cipher) * https://en.wikipedia.org/wiki/Speck_(cipher) https://en.wikipedia.org/wiki/Speck_(cipher) The ISO went with PRESENT and CLEFIA for ISO/IEC 29192 ("Information technology - Security techniques - Lightweight cryptography"): * https://en.wikipedia.org/wiki/PRESENT https://en.wikipedia.org/wiki/PRESENT * https://en.wikipedia.org/wiki/CLEFIA https://en.wikipedia.org/wiki/CLEFIA A bit of a history of that episode: * https://link.springer.com/chapter/10.1007/978-3-030-10591-4_4 https://link.springer.com/chapter/10.1007/978-3-030-10591-4_... S&S were eventually accepted for ISO 29167.

rdpintqogeogsaa 5y ago
SPECK is a really attractive design for software implementation. The key schedule and the round function are the same, it's an ARX design that lends itself to naturally constant-time implementation. If the design is free of fault and it gets thrown out because of its origin and admittedly questionable public analysis statements, that's rather unfortunate. Alas, it's hard to trust given the backstory, but on the other hand the author(s) might be relying entirely on cryptanalytic techniques and results they're not able to publish for whatever reason.
- GTP 5y ago
  >but on the other hand the author(s) might be relying entirely on cryptanalytic techniques and results they're not able to publish for whatever reason But this is bad, the best way to ensure that some cryptanalytic technique works is to publish it so every cryptographer in the world can review it.
  - espadrine 5y ago
    > the best way to ensure that some cryptanalytic technique works is to publish it so every cryptographer in the world can review it The best way to ensure that a design is sound, is to publish it, but that is not true of cryptanalysis techniques. They are generally tied to a mathematical proof, so they can be quite confident of their correctness. A design, on the other hand, has an unknown number of ways in which it can fail. Also, historically, secret cryptanalyses have proved invaluable in warfare; the most famous examples are the techniques used for Enigma, Lorenz SZ42, and the “Purple” Type B Cipher Machine, which allowed reading various crucial messages from the Nazi and Imperial Japan during WWII; had the techniques been published, the ciphers would have been improved. There is still a very good reason to not like that situation: first, commercial information is much more sizeable and is arguably much more sensitive nowadays, as warfare is shifting to the weakening of the enemies’ economy (look at Russia turning a blind eye or more on the groups behind the Colonial Pipeline hack). Second, the government’s cryptanalysis effort is financed by the people, so it would be reasonable for them to receive its fruits.
    - GTP 5y ago
      another reason to not like it: if there are out there ciphers which could be broken with such hypotetic tecnique we miss the chance to move away from them/design ciphers that are robust against that tecnique. which is exactly what secret services usually want to have a cryptographic advantage over enemies, but at the same time they endanger everyone else, as also the enemy coukd independently discover that tecnique and start using that against e.g. businesses.
  - MertsA 5y ago
    The NSA will never do that as it would be tipping their hand about whatever novel technique they reveal. In the past the NSA actually did provide some constants that went into DES and people were suspicious as the constants weren't randomly chosen. Later on it came out that differential cryptanalysis would have broken the original constants but the NSA provided ones were chosen to thwart this. They clearly knew about it well ahead of it being discovered in academia. Then you have the NSA's shady dealings around Dual_EC_DRBG where there was speculation that this might be similar to when the NSA secured DES against publicly unknown advanced cryptanalytic attacks. Of course for Dual_EC_DRBG that wasn't the case, it was a malicious backdoor, nothing more. The question comes down to "Is this a repeat of DES or Dual_EC_DRBG?" and the NSA has poisoned the well with their previous attack on cryptography standards.
- JoachimS 5y ago
  But both algorithms are confidentiality only, not AE. And they need a lot of rounds to provide any real security.

28194608 5y ago

Who won the encryption against quantum computer?

hannob 5y ago
You likely mean the nist post quantum competition, which is about public key encryption and signatures. The answer is noone yet, it's still running. Here's the list of proposals currently in the competition: https://csrc.nist.gov/Projects/post-quantum-cryptography/round-3-submissions https://csrc.nist.gov/Projects/post-quantum-cryptography/rou...
0xdeadb00f 5y ago
These are symmetric ciphers. So.. All of them?
- JoachimS 5y ago
  One thing though is that many lightweight block ciphers only have 128 bit keys. So in a PQ context, they will only provide 64 bit strength. Thus might be ok for short term secrets. But if you are building devices (IoT, SCADA) with long lifetimes, you may need to add a key derivation, key exchange scheme.

marcosdumay 5y ago

Last time I checked, all the computers were growing powerful and crypto was relevant neither for latency nor for power consumption on any device capable of joining a network. It helps that one of the largest factors on choosing crypto algorithms is speed on both general purpose and specialized hardware. So, count me in the group of people that don't understand why the NIST is doing this. Will they trade any security guarantee for speed? If so, nobody should ever use one of those algorithms. If not, whatever algorithm wins here would also win a new round of general purpose crypto contest.

wmf 5y ago
Check out the case of storage encryption in smartwatches and very cheap phones. The CPUs do not have AES instructions and doing software AES makes the watch noticeably sluggish. https://lwn.net/ml/linux-crypto/20180806223300.113891-1-ebiggers@kernel.org/ https://lwn.net/ml/linux-crypto/20180806223300.113891-1-ebig...
- marcosdumay 5y ago
  The question is, are you ok with the encryption being breakable if it makes your watch faster? Personally, if I'm ok with the encryption being breakable, I'm also ok with not using any encryption at all. I can't imagine a scenario where I would want weak encryption. Anyway, the way to solve that problem is to get a CPU with AES instructions.
  - wmf 5y ago
    That tradeoff doesn't exist. No one is proposing weak or breakable encryption. Even the fastest "lightweight" finalists provide full 128-bit security.
    - marcosdumay 5y ago
      If they have 128-bit security, what is the difference between that and a normal contest?

joelbondurant 5y ago

NEVER trust algorithms from extortion sector low life degenerate thugs.

ur-whale 5y ago

Can someone point to a resource describing why various candidates got rejected in round 1 and round 2? Any comments on the decisions or was it just voting without explaining?

rdpintqogeogsaa 5y ago
See NISTIR 8369, available from [0], p. 40 et seq. in particular. [0] https://csrc.nist.gov/publications/detail/nistir/8369/final https://csrc.nist.gov/publications/detail/nistir/8369/final

nemo1618 5y ago

One nice thing about lightweight crypto is that it's easy to port. Implementing ASCON in Go was pretty fun and only took an hour or two: https://github.com/lukechampine/ascon/blob/master/ascon.go https://github.com/lukechampine/ascon/blob/master/ascon.go (Obviously it wouldn't make a ton of sense to use Go if you're resource-constrained, but having a library is worthwhile for compatibility reasons regardless.)

JoachimS 5y ago

One really good thing with the finalist algorithms is that they all provide authenticated encryption. For many IoT systems, authentication and integrity protection is way more important than condidentiality. Many older lightweight algorithms (or AES) for that matter requires adding either an authentication mode, or another primitive (a hash function used in HMAC for example) I believe that has led to a problematic proliferation of only having confidentiality protection in too many IoT systems deployed. These candidates makes it easier for developers to add the security properties their system actually needs.