6 ms·
Transfer is one issue, processing is another. If you're running an IoT device on an STM32F423ZH (chosen because my employer has a cell-enabled IoT device on tha
by SAI_Peregrinus 6y ago
Transfer is one issue, processing is another. If you're running an IoT device on an STM32F423ZH (chosen because my employer has a cell-enabled IoT device on that MCU) you've got 320k of total RAM. Considering there's overhead for the rest of the application, there's no way to use such keys on such a device.
A trusted proxy works if ECC is secure (no quantum computers), but if quantum attacks are practical then there would be no way to verify that the trusted proxy is actually what you think it is.
- Dylan16807 6y ago> Considering there's overhead for the rest of the application, there's no way to use such keys on such a device. If you wait a small number of years you'll be able to get twice the ram at the same price. So "it would barely fit in ram if nothing else is running" doesn't seem like a significant barrier to me. > A trusted proxy works if ECC is secure (no quantum computers), but if quantum attacks are practical then there would be no way to verify that the trusted proxy is actually what you think it is. Your trusted proxy would be using one of the secure multi-megabyte keys, of course. Am I missing something about that arrangement? If signatures would also be enormous then we have a more significant problem to deal with than key size.
- SAI_Peregrinus 6y agoThe trusted proxy in your scheme exists to avoid needing to deal with the multi-megabyte keys on a device with only a few kilobytes of RAM. It CAN'T use such keys to secure the connection with the embedded device. If it could, it wouldn't be needed.