4 ms·

If I'm not missing anything, DJB does not consider constrained devices, where the code size and execution time with two algorithms may be a problem. Unfortunate

If I'm not missing anything, DJB does not consider constrained devices, where the code size and execution time with two algorithms may be a problem. Unfortunately these types of devices are also the types that may have very long lifetimes. But for all other devices - server, desktop, mobile phones etc which sports 64-bit CPUs clocked in GHz speeds, and GByte of storage, RAM this is seems sensible. Performing x25519 on these devices in addition to the PQC-algoritm should be a negligible cost.

adrian_b 3y ago
Constrained devices should rather stick to the existing key exchange methods, until more certainty exists about the threat of quantum computers. The current methods have much lower overhead than any of the post-quantum methods. Constrained devices that must be quantum-resistant while not affording the cost of hybrid algorithms, which are only slightly less expensive than pure post-quantum algorithms, should better use key-exchange methods based on pre-shared authentication keys, which have much lower overhead than the public-key methods. They could still use hybrid key exchange methods, but very infrequently, only for updating the pre-shared authentication keys, in which case the slowness of the hybrid key exchange method would not matter.
- JoachimS 3y ago
  The problem is that constrained devices with planned lifetimes of 20-30 years being specified today already are getting requests for inclusion, usage of PQC as well as classical algorithms. Pre-shared only works for deployments with low-ish number of devices. We are talking about 1000+ devices.
  - adrian_b 3y ago
    That is why I have said that if updating the pre-shared authentication keys through separate communication channels is impractical, they can be updated through hybrid public-key based key exchange methods. If a hybrid key exchange method is used e.g. only after one thousand or even after one hundred of connections made with pre-shared keys, then the hybrid method can be very slow without significant impact. This is the same like reusing in TLS 1.3 a previously computed shared secret for a new connection, just using this for a large enough number of successive connections so that the slowness of the constrained device does not matter.
  - michaelt 3y ago
    TLS-PSK is used in some of the largest volume resource constrained internet-connected devices in the world. You buy a $5 wifi-controlled lightbulb? There's a good chance it talks to its backend servers with TLS-PSK.
hannob 3y ago
These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. But given that cryptography is usually not very resource intensive to begin with (people often have incredibly wrong ideas about the actual computational costs of cryptography), and we increasingly have more powerful devices even in embedded settings, I doubt this is an actual problem.
- DyslexicAtheist 3y ago
  > These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. agree the term is extremely loaded. The closest "official" definition close to a "legal definition" comes out of ETSI 303645. This draft is the basis for what CENELEC is currently using to create an official standard which will become legislation for consumer IoT devices in Europe next year (Radio Equipment Directive / RED). constrained device: device which has physical limitations in either the ability to process data, the ability to communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its intended use NOTE 1: Physical limitations can be due to power supply, battery life, processing power, physical access, limited functionality, limited memory or limited network bandwidth. These limitations can require a constrained device to be supported by another device, such as a base station or companion device. EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device. EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware replacement or network isolation being the only options to manage a security vulnerability. EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations. Performing high power cryptographic operations would quickly reduce the battery life, so it relies on a base station or hub to perform validations on updates. EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing. EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information. NOTE 2: A device that has a wired power supply and can support IP-based protocols and the cryptographic primitives used by those protocols is not constrained. EXAMPLE 6: A device is mains powered and communicates primarily using TLS (Transport Layer Security). see https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02...

adrian_b 3y ago

Constrained devices should rather stick to the existing key exchange methods, until more certainty exists about the threat of quantum computers. The current methods have much lower overhead than any of the post-quantum methods. Constrained devices that must be quantum-resistant while not affording the cost of hybrid algorithms, which are only slightly less expensive than pure post-quantum algorithms, should better use key-exchange methods based on pre-shared authentication keys, which have much lower overhead than the public-key methods. They could still use hybrid key exchange methods, but very infrequently, only for updating the pre-shared authentication keys, in which case the slowness of the hybrid key exchange method would not matter.

JoachimS 3y ago
The problem is that constrained devices with planned lifetimes of 20-30 years being specified today already are getting requests for inclusion, usage of PQC as well as classical algorithms. Pre-shared only works for deployments with low-ish number of devices. We are talking about 1000+ devices.
- adrian_b 3y ago
  That is why I have said that if updating the pre-shared authentication keys through separate communication channels is impractical, they can be updated through hybrid public-key based key exchange methods. If a hybrid key exchange method is used e.g. only after one thousand or even after one hundred of connections made with pre-shared keys, then the hybrid method can be very slow without significant impact. This is the same like reusing in TLS 1.3 a previously computed shared secret for a new connection, just using this for a large enough number of successive connections so that the slowness of the constrained device does not matter.
- michaelt 3y ago
  TLS-PSK is used in some of the largest volume resource constrained internet-connected devices in the world. You buy a $5 wifi-controlled lightbulb? There's a good chance it talks to its backend servers with TLS-PSK.

hannob 3y ago

These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. But given that cryptography is usually not very resource intensive to begin with (people often have incredibly wrong ideas about the actual computational costs of cryptography), and we increasingly have more powerful devices even in embedded settings, I doubt this is an actual problem.

DyslexicAtheist 3y ago
> These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. agree the term is extremely loaded. The closest "official" definition close to a "legal definition" comes out of ETSI 303645. This draft is the basis for what CENELEC is currently using to create an official standard which will become legislation for consumer IoT devices in Europe next year (Radio Equipment Directive / RED). constrained device: device which has physical limitations in either the ability to process data, the ability to communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its intended use NOTE 1: Physical limitations can be due to power supply, battery life, processing power, physical access, limited functionality, limited memory or limited network bandwidth. These limitations can require a constrained device to be supported by another device, such as a base station or companion device. EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device. EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware replacement or network isolation being the only options to manage a security vulnerability. EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations. Performing high power cryptographic operations would quickly reduce the battery life, so it relies on a base station or hub to perform validations on updates. EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing. EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information. NOTE 2: A device that has a wired power supply and can support IP-based protocols and the cryptographic primitives used by those protocols is not constrained. EXAMPLE 6: A device is mains powered and communicates primarily using TLS (Transport Layer Security). see https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02...