From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon

"The team has decided to standardize the Ascon family for lightweight cryptography applications as it meets the needs of most use cases where lightweight cryptography is required. Congratulations to the Ascon team! NIST thanks all of the finalist teams
and the community members who provided feedback that contributed to the selection."

Ascon's claim to fame is that it provides Authenticated encryption with associated data (AEAD) more efficiently than AES-GCM etc. It also hashes. Getting NIST's blessing is a huge win that opens a lot of doors.

The team's website is https://ascon.iaik.tugraz.at/ which points to many years of technical papers as well as hardware and software implementations.

ANS Forth is not in the list, FYI. In case someone wants to implement Ascon in Forth.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 15, 2023 at 8:01:07 AM UTC+2, Brad Eckert wrote:

From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon

When encryption is needed, who'd select an algorithm that is less secure
than others, and is promoted by a government controlled agency :--)

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <c56c5b10-0993-4362-891e-6fd269dfd6f4n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:

On Sunday, October 15, 2023 at 8:01:07 AM UTC+2, Brad Eckert wrote:

From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon

When encryption is needed, who'd select an algorithm that is less secure
than others, and is promoted by a government controlled agency :--)

It is easy to implement a secure RSA encryption with tools like dc bc.
All data concerning the U-bot in France during world war II fits in a
10 K file. That is 80,000 bits and 40 loops of a 2048 bit RSA.

Even if it cost one minute per loop, that is bearable. On the premise
that the data is worth encrypting.

What the industry wants is encrypt data that shouldn't like video's.
There speed is of paramount importance, or it becomes a big nuisance.

-marcel

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix schrieb am Sonntag, 15. Oktober 2023 um 11:12:22 UTC+2:

On Sunday, October 15, 2023 at 8:01:07 AM UTC+2, Brad Eckert wrote:

From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon

When encryption is needed, who'd select an algorithm that is less secure than others, and is promoted by a government controlled agency :--)

No reason for paranoia:

The chosen algorithms are designed to protect information created and transmitted by the Internet of Things (IoT), including its myriad tiny sensors and actuators. They are also designed for other miniature technologies such as implanted medical devices,
stress detectors inside roads and bridges, and keyless entry fobs for vehicles. Devices like these need “lightweight cryptography” — protection that uses the limited amount of electronic resources they possess. According to NIST computer scientist
Kerry McKay, the newly selected algorithms should be appropriate for most forms of tiny tech.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 15, 2023 at 9:00:52 PM UTC+2, minforth wrote:

Marcel Hendrix schrieb am Sonntag, 15. Oktober 2023 um 11:12:22 UTC+2:

[..]

No reason for paranoia:

[..]
Why encrypt something if it is unimportant? I understand that the implementation
should be lightweight but don't see why 'easier' algorithms should be used.

<rant>
A not insignificant amount of my working day is spent logging in/out, finding and
renewing passwords, checking my phone for two-factor authentications that take minutes to appear when IT updates a Linux server in India, trying to access simple
documents through horrendously layered Teams and Outlook "protections", fighting
with management that wants to abolish USB-sticks and network drives, and attending
mandatory safety drills that preach the use of long complicated passwords that shall
subsequently be saved in OneDrive repositories coupled to our Microsoft accounts :--)
</rant>

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix schrieb am Sonntag, 15. Oktober 2023 um 21:26:03 UTC+2:

On Sunday, October 15, 2023 at 9:00:52 PM UTC+2, minforth wrote:

Marcel Hendrix schrieb am Sonntag, 15. Oktober 2023 um 11:12:22 UTC+2:

[..]

No reason for paranoia:

[..]
Why encrypt something if it is unimportant? I understand that the implementation
should be lightweight but don't see why 'easier' algorithms should be used.

Lightweight and "burning time and milliwatts for convoluted algrithms" don't go well together.
It should be obvious that not every smart sensor requires military strength encryption.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 15, 2023 at 9:26:03 PM UTC+2, Marcel Hendrix wrote:

On Sunday, October 15, 2023 at 9:00:52 PM UTC+2, minforth wrote:

Marcel Hendrix schrieb am Sonntag, 15. Oktober 2023 um 11:12:22 UTC+2:

[..]

No reason for paranoia:

[..]
Why encrypt something if it is unimportant? I understand that the implementation
should be lightweight but don't see why 'easier' algorithms should be used.

<rant>
A not insignificant amount of my working day is spent logging in/out, finding and
renewing passwords, checking my phone for two-factor authentications that take
minutes to appear when IT updates a Linux server in India, trying to access simple
documents through horrendously layered Teams and Outlook "protections", fighting
with management that wants to abolish USB-sticks and network drives, and attending
mandatory safety drills that preach the use of long complicated passwords that shall
subsequently be saved in OneDrive repositories coupled to our Microsoft accounts :--)
</rant>

-marcel

Hi Marcel,
An excellent rant, that I wholeheartedly agree with - I would add the estimated 15% of my waking time spent in making sure that all my intelligent devices are charged ;-)
Cheers,
Howerd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 15 October 2023 at 20:00:52 UTC+1, minforth wrote:

Marcel Hendrix schrieb am Sonntag, 15. Oktober 2023 um 11:12:22 UTC+2:

On Sunday, October 15, 2023 at 8:01:07 AM UTC+2, Brad Eckert wrote:

From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon

When encryption is needed, who'd select an algorithm that is less secure than others, and is promoted by a government controlled agency :--)

No reason for paranoia:

The chosen algorithms are designed to protect information created and transmitted by the Internet of Things (IoT), including its myriad tiny sensors and actuators. They are also designed for other miniature technologies such as implanted medical

devices, stress detectors inside roads and bridges, and keyless entry fobs for vehicles. Devices like these need “lightweight cryptography” — protection that uses the limited amount of electronic resources they possess. According to NIST computer
scientist Kerry McKay, the newly selected algorithms should be appropriate for most forms of tiny tech.


How quickly you forgot : https://www.scientificamerican.com/article/nsa-nist-encryption-scandal/

---
Fool Me Once, Shame on You; Fool Me Twice, Shame on Me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 15, 2023 at 7:12:22 PM UTC+10, Marcel Hendrix wrote:

On Sunday, October 15, 2023 at 8:01:07 AM UTC+2, Brad Eckert wrote:

From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon

When encryption is needed, who'd select an algorithm that is less secure than others, and is promoted by a government controlled agency :--)

-marcel

Well, it's better than the nocrypt standard.

:)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/10/2023 3:42 pm, S wrote:

On Sunday, October 15, 2023 at 7:12:22 PM UTC+10, Marcel Hendrix wrote:

On Sunday, October 15, 2023 at 8:01:07 AM UTC+2, Brad Eckert wrote:

From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon

When encryption is needed, who'd select an algorithm that is less secure
than others, and is promoted by a government controlled agency :--)

-marcel

Well, it's better than the nocrypt standard.

:)

What is "less secure"? AFAIK most hacks are opportunistic e.g. Enigma

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, October 19, 2023 at 10:50:51 PM UTC-7, dxf wrote:

On 20/10/2023 3:42 pm, S wrote:

On Sunday, October 15, 2023 at 7:12:22 PM UTC+10, Marcel Hendrix wrote:

On Sunday, October 15, 2023 at 8:01:07 AM UTC+2, Brad Eckert wrote:

From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon

When encryption is needed, who'd select an algorithm that is less secure >> than others, and is promoted by a government controlled agency :--)

-marcel

Well, it's better than the nocrypt standard.

:)

What is "less secure"? AFAIK most hacks are opportunistic e.g. Enigma

I spent a couple of days translating the C version of Ascon to Forth. I got it to encrypt and decrypt correctly but haven't beat on it yet. In 32-bit SwiftForth it uses 4300 bytes of dictionary. So maybe 1K on the J1? Anyway... Some observations.

I can see why it won. It's very friendly to 64-bit machines. There are no 64-bit IoTs, but those IoTs connect to servers which are 64-bit. It's also good on 32-bit, 16-bit, and 8-bit MCUs according to the benchmarks. It's no surprise looking at the C
code. A 64-bit version of Ascon would make a nice Forth compiler benchmark.

AEAD (see https://en.wikipedia.org/wiki/Authenticated_encryption) is the real selling point. Decryption checks the 128-bit tag at the end and returns a nonzero ior if it's not a match. The hash includes optional unencrypted data such as headers. It turns
out that authenticity is more important than privacy when it comes to potential "bad things".

You may wonder why anyone would want to adopt yet another cryptography algorithm when so many already exist. Today's cybersecurity attacks cost millions of dollars. IoTs are often attack vectors. The IoT dumpster fire was funny until it got expensive.
Where there are these kinds of losses there are lawyers and regulators and eventually regulations. When cybersecurity standards are shoved down your throat, you will read in the fine print that they want NIST-approved algorithms. Not the one you picked
because you happen to like it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/10/2023 11:48 pm, Brad Eckert wrote:

...
When cybersecurity standards are shoved down your throat, you will read in the fine print that they want NIST-approved algorithms. Not the one you picked because you happen to like it.

Good point. OTOH standards set minimums - often based on what industry is prepared to wear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Brad Eckert schrieb am Sonntag, 22. Oktober 2023 um 14:48:24 UTC+2:

On Thursday, October 19, 2023 at 10:50:51 PM UTC-7, dxf wrote:

On 20/10/2023 3:42 pm, S wrote:

On Sunday, October 15, 2023 at 7:12:22 PM UTC+10, Marcel Hendrix wrote:

On Sunday, October 15, 2023 at 8:01:07 AM UTC+2, Brad Eckert wrote: >>> From NIST's news release on February 07, 2023:

Lightweight Cryptography Standardization Process: NIST Selects Ascon >> When encryption is needed, who'd select an algorithm that is less secure

than others, and is promoted by a government controlled agency :--)

-marcel

Well, it's better than the nocrypt standard.

:)

What is "less secure"? AFAIK most hacks are opportunistic e.g. Enigma

I spent a couple of days translating the C version of Ascon to Forth. I got it to encrypt and decrypt correctly but haven't beat on it yet. In 32-bit SwiftForth it uses 4300 bytes of dictionary. So maybe 1K on the J1? Anyway... Some observations.

I can see why it won. It's very friendly to 64-bit machines. There are no 64-bit IoTs, but those IoTs connect to servers which are 64-bit. It's also good on 32-bit, 16-bit, and 8-bit MCUs according to the benchmarks. It's no surprise looking at the C

code. A 64-bit version of Ascon would make a nice Forth compiler benchmark.

AEAD (see https://en.wikipedia.org/wiki/Authenticated_encryption) is the real selling point. Decryption checks the 128-bit tag at the end and returns a nonzero ior if it's not a match. The hash includes optional unencrypted data such as headers. It

turns out that authenticity is more important than privacy when it comes to potential "bad things".

You may wonder why anyone would want to adopt yet another cryptography algorithm when so many already exist. Today's cybersecurity attacks cost millions of dollars. IoTs are often attack vectors. The IoT dumpster fire was funny until it got expensive.

Where there are these kinds of losses there are lawyers and regulators and eventually regulations. When cybersecurity standards are shoved down your throat, you will read in the fine print that they want NIST-approved algorithms. Not the one you picked
because you happen to like it.

Excellent summary!

Today the majority of wireless transmitters use the Wireless HART protocol with AES-128 encrytion.
This will not change anytime soon, unless required by law/contract for new critical infrastructure projects.

Neither Ascon nor AES-128 are strong encryptions. And ISTM that AES-128 is even easier to implement
than Ascon. But AES has a longer attack history and therefore is more compromised.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)