i don't think cryptographers should be allowed to write cryptographic specifications
i understand that this is very precise but if you're trying to implement the algorithm it adds _so_ much overhead
i don't think cryptographers should be allowed to write cryptographic specifications
i understand that this is very precise but if you're trying to implement the algorithm it adds _so_ much overhead
this is an xor operation described as "constant addition", right
is the and operation implicit
what is the operation precedence here
@lesley it took me several years to grasp the PL research notation, but at least there it adds actual value
the Ascon spec feels like it's written to be obscure. the algorithm is very simple, it's just described in a crackhead manner
@whitequark Reminds me of PL research with its arcane notation involving a lot of Γ, ∆, ⊢, and τ.
Also reminds me of this video: https://youtu.be/33y9FMIvcWY?si=FjgQDjaKryIvyQUu
what would possess someone to describe xor with a 8-bit number as a 64-bit addition
this is going to be implemented in a programming language. copied from a pdf and symbols replaced
omitting multiplication operators, while natural from a math point of view, makes this _so_ much more painful
@whitequark honestly seems more like the kind of thing that would end up in some "is this primitive turing complete" ML paper
cryptographers: addition is +, xor is ⊕
same cryptographers: now we're gonna use the word "addition" for xor
it's not that i'm missing something, this paper is just poorly written
also they don't specify the endianness of concatenation. why is it pointlessly verbose where it doesn't matter, and not verbose enough where it does
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.