4 ms·

For instance, the devices we make are not powerful enough to use the standard crypto algorithms. So we are looking forward to the results. Security, for us, onl

For instance, the devices we make are not powerful enough to use the standard crypto algorithms. So we are looking forward to the results. Security, for us, only has to be guaranteed for a limited time: if it cannot be cracked in a few minutes, it does not matter if it ever does. So we benefit from 'not as secure but secure enough'. Edit; by not powerful enough, we mean both: too high latency and too much energy drain.

marcosdumay 5y ago
If you create an encryption schema designed to survive a few hours of attack, it will automatically be vulnerable to the attacker negotiating a discount with a CPU manufacturer.
oleganza 5y ago
Would you mind sharing what protocols you are working on that can benefit from a "lightweight cryptography"? My impression from learning cryptography in the last 8 years is that cryptographic protocols are either exponentially secure, or any tiny weaknesses can be amplified into a complete break. The only example of secure "intrapolynomial cryptography" [1] is Proof-of-Work, but it also requires work to be expended continuously. Not exactly a scheme for "underpowered devices". [1] https://nakamotoinstitute.org/intrapolynomial-cryptography/ https://nakamotoinstitute.org/intrapolynomial-cryptography/
- tluyben2 5y ago
  That is why NIST is doing this; most IoT I am aware of, including ours, needs a very secure channel, but for a relative short(er) time. So if it takes 6 hours minimum to decrypt it without having the private key, that would be fine for us and most IoT (that I have seen anyway) but bad for most general purpose computing, where you want 'infinite time' security if you can get it. I think it is a different and undervalued market, resulting often in bad security practices because we have no alternatives. The MCUs we use cost cents and are measured in mhz speed and kbs memory. They do have cryptographic co units but those are not very fast either while generic crypto algos tend to demand more and more power to guarantee longer periods of being decrypted by bad actors. Edit: note that we are using RSA and, lately, Ed25519, but it takes 5-6s for the heaviest Ops and that is simply way too long. It is however secure and it works, so if that is it than that is it, it is just overkill mostly for what we need.
  - oleganza 5y ago
    What happens after 6 hours? Let's say I capture all the data from all the sensors and decrypt it with a 24 hr lag. I don't get a real-time info, but i collect all the patterns and whatever long-term data that's accidentally sent out.
    - tluyben2 5y ago
      The data needs to reach a server within that period (the real period is much shorter: 5 minutes currently, but it might be 1-2 hours in the future); if it comes in after that, the server will find it invalid and drop it. We currently have it completely secure (modern ECC for instance): we have created a hybrid which refreshes a low power latency/power private key using the traditional means which gives us windows long enough to have low latency and lower power usage while ensuring the encryption holds. Something globally accepted would be better obviously. We have many more prototypes of things we evaluated ourselves but need help (if you know someone with these credentials) with just to solve the latency and power consumption issue.
      - oleganza 5y ago
        So the server and device securely agree on something like TOTP list (weak keys with expiration date), so intermediate data can be authenticated within those time windows? But if that applies to encryption too, then won't later bruteforced decryption pose a threat?
_3u10 5y ago
Why not use RC4? How resource constrained are you? Doesn’t most of your networking gear have crypto built into it already?
- JoachimS 5y ago
  Apart from being broken RC4 requires 256 bytes of state, have a very slow key change operation. And is actually quite slow. Most modern lightweight ciphers requires much less state (can be stored in registers even), has good key agility. And are faster. So there are numerous technical reasons to not use RC4. As long as you don't have legacy requirements, don't use RC4.
- tptacek 5y ago
  Because RC4 is probably the most egregiously broken cipher that has ever been in common use.
  - tialaramex 5y ago
    And this is actually an interesting line in the sand here. SPECK is probably fine. It's a pretty ordinary-looking design, if some 25 year old up-and-coming crypto academic proposed this for an application, nobody would freak out about how maybe it's a cunning trick to steal all our data. But because the NSA was involved and wasn't willing to share whatever methods they're currently using to check this was OK that's apparently reason to shoot it down. And even though RC4 is very broken (unlike SPECK) it'd still actually be a lot of work to attack many practical applications of RC4. One of the strange things the Web gave us is a real application that looks like the outrageously convenient models in a cryptography class. Want one of the participants to repeatedly send a known plaintext using millions of different keys so you can see what that looks like? Javascript! Need to ensure your payload data is right next to the mystery data you need to decrypt? Cookies! Need to convince a participant to connect to your hostile system and decrypt large volumes of data? Embedded images and HTML email! So on the web, you can build a toy demo that breaks RC4, not really in a real time (I guess at a multi-day conference you could do an afternoon session "Preparing to break RC4" and then a morning session the next day "See, it worked") but for most protocols the attack is not practical. Attacks of course, only get better, so, this is not telling anybody to use RC4 but only underscoring how high the bar is here. Should you use RC4? No. Definitely not. But is the RC4-encryption for the IoT data feed the weakest link in your system today? Almost certainly also no.
adament 5y ago
If you have a need for lightweight cryptography today, why wait for the NIST competition? Ascon is already the primary recommendation in the lightweight category from the CAESAR competition, and now also a finalist in the NIST competition.
- rdpintqogeogsaa 5y ago
  There's probably going to be a strong ecosystem pull towards the winner of any NIST competition. Betting on ASCON too early may mean losing out on mainstream library support. Considering “don't roll your own crypto” is still a golden rule, it seems better to leave the issue alone if you at all can until everyone catches up.

marcosdumay 5y ago

If you create an encryption schema designed to survive a few hours of attack, it will automatically be vulnerable to the attacker negotiating a discount with a CPU manufacturer.

oleganza 5y ago

Would you mind sharing what protocols you are working on that can benefit from a "lightweight cryptography"? My impression from learning cryptography in the last 8 years is that cryptographic protocols are either exponentially secure, or any tiny weaknesses can be amplified into a complete break. The only example of secure "intrapolynomial cryptography" [1] is Proof-of-Work, but it also requires work to be expended continuously. Not exactly a scheme for "underpowered devices". [1] https://nakamotoinstitute.org/intrapolynomial-cryptography/ https://nakamotoinstitute.org/intrapolynomial-cryptography/

tluyben2 5y ago
That is why NIST is doing this; most IoT I am aware of, including ours, needs a very secure channel, but for a relative short(er) time. So if it takes 6 hours minimum to decrypt it without having the private key, that would be fine for us and most IoT (that I have seen anyway) but bad for most general purpose computing, where you want 'infinite time' security if you can get it. I think it is a different and undervalued market, resulting often in bad security practices because we have no alternatives. The MCUs we use cost cents and are measured in mhz speed and kbs memory. They do have cryptographic co units but those are not very fast either while generic crypto algos tend to demand more and more power to guarantee longer periods of being decrypted by bad actors. Edit: note that we are using RSA and, lately, Ed25519, but it takes 5-6s for the heaviest Ops and that is simply way too long. It is however secure and it works, so if that is it than that is it, it is just overkill mostly for what we need.
- oleganza 5y ago
  What happens after 6 hours? Let's say I capture all the data from all the sensors and decrypt it with a 24 hr lag. I don't get a real-time info, but i collect all the patterns and whatever long-term data that's accidentally sent out.
  - tluyben2 5y ago
    The data needs to reach a server within that period (the real period is much shorter: 5 minutes currently, but it might be 1-2 hours in the future); if it comes in after that, the server will find it invalid and drop it. We currently have it completely secure (modern ECC for instance): we have created a hybrid which refreshes a low power latency/power private key using the traditional means which gives us windows long enough to have low latency and lower power usage while ensuring the encryption holds. Something globally accepted would be better obviously. We have many more prototypes of things we evaluated ourselves but need help (if you know someone with these credentials) with just to solve the latency and power consumption issue.
    - oleganza 5y ago
      So the server and device securely agree on something like TOTP list (weak keys with expiration date), so intermediate data can be authenticated within those time windows? But if that applies to encryption too, then won't later bruteforced decryption pose a threat?

_3u10 5y ago

Why not use RC4? How resource constrained are you? Doesn’t most of your networking gear have crypto built into it already?

JoachimS 5y ago
Apart from being broken RC4 requires 256 bytes of state, have a very slow key change operation. And is actually quite slow. Most modern lightweight ciphers requires much less state (can be stored in registers even), has good key agility. And are faster. So there are numerous technical reasons to not use RC4. As long as you don't have legacy requirements, don't use RC4.
tptacek 5y ago
Because RC4 is probably the most egregiously broken cipher that has ever been in common use.
- tialaramex 5y ago
  And this is actually an interesting line in the sand here. SPECK is probably fine. It's a pretty ordinary-looking design, if some 25 year old up-and-coming crypto academic proposed this for an application, nobody would freak out about how maybe it's a cunning trick to steal all our data. But because the NSA was involved and wasn't willing to share whatever methods they're currently using to check this was OK that's apparently reason to shoot it down. And even though RC4 is very broken (unlike SPECK) it'd still actually be a lot of work to attack many practical applications of RC4. One of the strange things the Web gave us is a real application that looks like the outrageously convenient models in a cryptography class. Want one of the participants to repeatedly send a known plaintext using millions of different keys so you can see what that looks like? Javascript! Need to ensure your payload data is right next to the mystery data you need to decrypt? Cookies! Need to convince a participant to connect to your hostile system and decrypt large volumes of data? Embedded images and HTML email! So on the web, you can build a toy demo that breaks RC4, not really in a real time (I guess at a multi-day conference you could do an afternoon session "Preparing to break RC4" and then a morning session the next day "See, it worked") but for most protocols the attack is not practical. Attacks of course, only get better, so, this is not telling anybody to use RC4 but only underscoring how high the bar is here. Should you use RC4? No. Definitely not. But is the RC4-encryption for the IoT data feed the weakest link in your system today? Almost certainly also no.

adament 5y ago

If you have a need for lightweight cryptography today, why wait for the NIST competition? Ascon is already the primary recommendation in the lightweight category from the CAESAR competition, and now also a finalist in the NIST competition.

rdpintqogeogsaa 5y ago
There's probably going to be a strong ecosystem pull towards the winner of any NIST competition. Betting on ASCON too early may mean losing out on mainstream library support. Considering “don't roll your own crypto” is still a golden rule, it seems better to leave the issue alone if you at all can until everyone catches up.