[HN Gopher] Lightweight Cryptography
___________________________________________________________________
Lightweight Cryptography
Author : rdpintqogeogsaa
Score : 119 points
Date : 2021-11-07 09:48 UTC (13 hours ago)
(HTM) web link (csrc.nist.gov)
(TXT) w3m dump (csrc.nist.gov)
| nemo1618 wrote:
| 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
|
| (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.)
| 28194608 wrote:
| Who won the encryption against quantum computer?
| 0xdeadb00f wrote:
| These are symmetric ciphers. So.. All of them?
| hannob wrote:
| 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/rou...
| throw0101a wrote:
| 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...
|
| * https://en.wikipedia.org/wiki/Simon_(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/CLEFIA
|
| A bit of a history of that episode:
|
| * https://link.springer.com/chapter/10.1007/978-3-030-10591-4_...
|
| S&S were eventually accepted for ISO 29167.
| rdpintqogeogsaa wrote:
| 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 wrote:
| >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 wrote:
| > _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 wrote:
| 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.
| marcosdumay wrote:
| 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 wrote:
| 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-ebig...
| marcosdumay wrote:
| 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 wrote:
| That tradeoff doesn't exist. No one is proposing weak or
| breakable encryption. Even the fastest "lightweight"
| finalists provide full 128-bit security.
| tluyben2 wrote:
| 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 wrote:
| 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.
| _3u10 wrote:
| Why not use RC4?
|
| How resource constrained are you? Doesn't most of your
| networking gear have crypto built into it already?
| tptacek wrote:
| Because RC4 is probably the most egregiously broken cipher
| that has ever been in common use.
| tialaramex wrote:
| 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.
| _3u10 wrote:
| Exactly. Is it broken? Yes.
|
| Am I going to buy a GPU or a wrench to crack a password?
| Most definitely a wrench.
|
| I honestly do think if the data only has to be protected
| for a day, just use RC4 (or something similar).
|
| It's pretty obvious the data is worth nothing if it's not
| even worth an extra battery to properly encrypt.
| adament wrote:
| 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 wrote:
| 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.
| oleganza wrote:
| 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/
| tluyben2 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| 60Vhipx7b4JL wrote:
| Every thought about all the things besides personal computers
| and smartphones?
|
| Embedded applications, energy limited (battery, power
| harvesting) devices, IoT, other resource constrained devices?
|
| I also doubt that more processing = more security.
| 0xdeadb00f wrote:
| The biggest use case for these algorithms is IoT, and other
| resource constrained embedded devices. Quite frankly, I'm
| surprised you didn't consider it seeing as insecure IoT devices
| have been in the news pretty much since they hit the market.
|
| Embedded devices, especially specialised ones arent poweful
| enough to operate sufficiently while also providing protection
| via the current "standard" crypto algorithms.
| mindslight wrote:
| The problem with Internet of Trash devices isn't a lack of
| cryptography - it's closed, poorly developed, throw-away
| software. In comparison to implementing a whole wifi stack,
| some dedicated hardware for AES is trivial. Given that NSA
| has been trying to get us to use "lightweight cryptography"
| for decades (eg 512 bit RSA), this seems quite uncompelling.
|
| Furthermore for even smaller devices without Wifi, the
| "Internet" of things (where Internet means communicating
| directly over the WAN rather than to a more-capable local
| device) won't be compelling until the software situation has
| been sorted out. For example the best practices for using
| current Wifi smart plugs is to stick them on their own VLAN
| with no Internet access, communicating only with a local Home
| Assistant or whatever. There's no reason they themselves need
| to be on the WAN.
| loeg wrote:
| A lot of the problems with IoT devices are things like
| hardcoded keys or passwords shared across all units. LWC
| doesn't fix that kind of design problem. I agree LWC has
| value but I think most IoT products are less cpu-limited and
| more engineer-limited.
| hannob wrote:
| Pretty much every IoT device uses Wifi, and that doesn't seem
| to be a problem right now. They all seem to be perfectly
| capable of speaking WPA2 with AES.
| Lifelarper wrote:
| > all the computers
|
| Maybe those machines that don't even spin up a fan with 400 npm
| dependencies, but billions of of low end embedded devices
| pumped out annually.
|
| Call me a sceptic but I think the lightcrypto contest is
| actually something that will benefit society far more than the
| post-quantum simultaneously underway.
| marcosdumay wrote:
| The processing needs of a wifi connection (or any wireless
| protocol) are overwhelming on dealing with the problems of a
| radio connection. Unless you are connecting, sending a single
| package and disconnecting1, encryption barely registers.
|
| For wired devices things changes a bit. Encryption can be
| dozens of times more expensive than moving your data around
| for processing. But if that's a problem, you need to
| accelerate your encryption in hardware2, not to weaken the
| encryption.
|
| 1 - If you are, you are better with some protocol that keeps
| the encryption setup around between transmissions, not with
| weaker crypto.
|
| 2 - Just like you accelerate the "moving data around" part,
| because it doesn't go from the network into the main memory
| for free either.
| joelbondurant wrote:
| NEVER trust algorithms from extortion sector low life degenerate
| thugs.
| ur-whale wrote:
| 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 wrote:
| See NISTIR 8369, available from [0], p. 40 _et seq._ in
| particular.
|
| [0] https://csrc.nist.gov/publications/detail/nistir/8369/final
___________________________________________________________________
(page generated 2021-11-07 23:01 UTC)