Ascon is a stream-oriented AEAD, not a block cipher, and it requires a nonce. Because of this, it would not work for the usecases in TFA, not to mention it's also quite a bit slower than Speck.

In the context of encrypting 32 or 64 bit IDs, where there is no nonce, that'd be equivalent to XOR encryption and much weaker than TFA's small block ciphers.

If you really want to encrypt and decrypt 32-bit numbers without having any nonces available, the fastest way on non-microcontroller CPUs remains using the AES instructions.

You can exploit the fact that the core of AES consists of 32-bit invertible mixing functions. In order to extend AES to 128-bit, a byte permutation is used, which mixes the bytes of the 32-bit words.

The AES instructions are such, that you can cancel the byte permutation. In this case, you can use the AES instructions to encrypt separately four 32-bit words, instead of one 128-bit block.

Similarly by canceling the standard byte permutation and replacing it with separate permutations on the 2 halves, you can make the AES instructions independently encrypt two 64-bit words.

These AES modifications remain faster than any software cipher.

How to cancel the internal permutation and replace it with external shuffle instructions was already described in the Intel white paper published in 2010, at the launch of Westmere, the first CPU with AES instructions.

Are you certain using AES is still faster? Let's say for a 32-bit block size and 64-bit key.

From https://en.wikipedia.org/wiki/Speck_(cipher), that Speck combination would use 22 rounds, and using the instruction timings for Zen 5 from https://instlatx64.github.io/InstLatx64/AuthenticAMD/Authent..., it looks like each round would take at most 3 cycles. (Dependency chain for each round is 3 instructions long, ror+add+xor). 22*3 = ~66 cycles.

Using AES with a pshufb to take out the ShiftRows step would be 2 cycles for the pshufb and 4 cycles for each aesenc, and at 10 rounds, you have ~60 cycles.

It's quite close, and to say which one wins, we'd need to actually benchmark it. One is not clearly much faster than the other.

maybe the reason they are so close is that the AES microcode is inplementing exactly those operations

There's nothing similar about AES and Speck, and the "microcode" for AES isn't like what you're thinking of. If you want to learn more about it, you can look up the specifications for AES and Intel's AES instruction set.

Would it, though? Either way you're operating in ECB mode with 2^32 or 2^64 values. Why is one more secure than the other?

EDIT: What I mean is you can do cypher = truncate(plain ^ AES(zero_extend(plain))).

>EDIT: What I mean is you can do cypher = truncate(plain ^ AES(zero_extend(plain))).

How would you decrypt that though? You truncated 3/4ths of the AES output needed to decrypt it.

I thought you were suggesting this:

  ciphertext = truncate(AES(key) ^ plaintext)

And in this case, since AES(key) does not depend on the plaintext, it would just be XOR by a constant.

You're right, my bad. I guess if you have strict size requirements it does make sense to use small block sizes.

Their wiki is what sold me on Arch. I ended up there solving most of my problems on other distros, and if they can make such a fine wiki, I figured they could make a great OS (which they did).

I was definitely the same way at one point but it's worth mentioning that the wiki remains a valuable resource even if you aren't using Arch itself.

e.g., NixOS just links to the archwiki page here for help with systemd timers: https://nixos.wiki/wiki/Systemd/Timers

Yep. Wiki and AUR completeness are hard to pass by.

I came here to post a similar comment. I decided to use Arch because the documentation is amazing. And I wasn't disappointed. It's become my favorite distro.

Me too, I started with Debian but after a few weeks, I found myself being more on the Arch wiki than the Debian's one so I did the switch and never used any other distro.

I'm sorry to say this but Debian's documentation sucked a lot some years ago.

I assume this is sarcasm, given your other comments? Even if it is, it's still quite rude.

>They totally forgot about not compiling invalid code.

Indeed. For a specific example of it not erroring out:

https://www.reddit.com/r/Compilers/comments/1qx7b12/comment/...

Professional-Managerial Class, as opposed to working class or proletariat.

Thanx, I don't consider myself PMC, but, I guess that's the internet of today, slap a label onto anyone and anything based on ~160 chars.

I guess lyu07282 is what I have taken to calling a "Judger". Always labeling, always judging, always seeking the moral high-ground, never realizing the lack of nuance that must exist in short texts. Never thinking "what if this was meant in a kind way." Oh, and I see the irony, it is intentional (feels bad right?).

I think it's what tearing the US apart at this very moment. Always Us against Them. Most people are kind you know. I really thought I did my best to add nuance.

The issue is that it's missing the include paths. The compiler itself is fine.

Thank you. That was a long article that started with a claim that was backed up by no proof, dismissing it as not the most interesting thing they were talking about when in fact it's the baseline of the whole discussion.

Looks like these users are just missing glibc-devel or equivalent?

Naa, it looks like it's failing to include the standard system include directories. If you take then from gcc and pass them as -I, it'll compile.

Can confirm (on aarch64 host)

    $ ./target/release/ccc-arm -I /usr/include/ -I /usr/local/include/ -I /usr/lib/gcc/aarch64-redhat-linux/15/include/ -o hello hello.c 

    $ ./hello
    Hello from CCC!

Seems this non-artificial intelligence model just too limited to understand concept of include path.

It’s machine specific

Hmm, I didn't have to do that. https://i.imgur.com/OAEtgvr.png

But yeah, either way it just needs to know where to find the stdlib.

Probably depends on where your distro puts stuff by default, I think it has a few of the common include paths hardcoded.

Makes sense for the behavior.

AI is the future.

This is truly incredible.

What about all those Windows on ARM laptops?

I do

I played around with it, and it's very neat. This is the first time I've seen an assembly REPL and I wish I had something like this that ran native for playing with unfamiliar instructions.

I did find a couple minor issues with the simulator: MVN is supposed to be a bitwise NOT but the simulator does a two's-complement negation instead (https://github.com/rtybanana/irisc-web/blob/main/src/interpr...), and it seems negative immediate offsets aren't supported, e.g.

  ldr r0, [r1, #-4]

Thanks for the bug reports, if you like you can open some issues for those and I’ll look into them ASAP.

Interesting about the bitwise NOT, I’ll need to dig up the manual on this I must have missed that.