Hi Peter, I don’t know what value did you use for mod, but my first guess would be that Keccak512 produces a value that is too big and so overflows, I believe this or next lesson mentions this flaw. Bear in mind that this is a very simplistic RSA implementation, but some things you can do is choosing a modulo bigger that 2^512 or reducing the hash value by the same modulo while signing and verifying. Hope this helps

Can anyone in the community provide a concise explanation for why finding the nonce such that the hash of the block is less than the current target is of value to the cryptocurrency process? I understand that the need for a brute force calculation causes mining to be energy intensive but I don’t see why it is important that the nonce have the indicated property.

The following is from Lesson 23 of the Wolfram cryptography.
“To commit a new block to the history of Bitcoin transactions, a peer must discover by brute force a nonce value that, when included in the block, results in an acceptable hash that is less than or equal to the current target set by the Bitcoin network. This process is called mining. The miner is rewarded some bitcoins for performing this computation.”

Thanks for any help you can provide on this question

Bitcoin "proof-of-work" mechanism results in high energy consumption mining. Does proof-of-stake /proof-of-storage have similar energy consumption overheads ?

Thank you everyone for warm words - it is such a good feeling to know the hard work we've put into this study group and MOOC paid off and people have learned something interesting! Special thanks to those who've attended every session and actively participated, your engagement is inspiring to me!

Dear Dariia,

Please let me join the number of people who have already thanked you for an amazing course and an equally amazing Daily Study Group Community--we learned a lot from both. Your excellent lectures and materials, lively discussions, stimulating examples, and excellent references will continue to let us grow.

Zbigniew Kabala, Associate Professor
Duke University

May be of interest to the attendees: Incorrectly Generated RSA Keys How To Recover Lost Plaintexts https://eprint.iacr.org/2020/1059.pdf

I appreciate your feedback, Michael, many thanks.

Thanks, Michael, you're right and I removed those attachments. Best, Mojtaba

Thank you for your interest and comments, Michael. Please see the attachment.

Attachments:

CommunityThread.pdf

And for the abstract of a talk I gave on this in the 43rd Australasian Combinatorics Conference in December, see:

https://www.mathematics.org.au/sys/public/talk.php?conf_id=54&talk=5873

Yes, thanks to all. And anyone who would be interested in a map from 2^363 to {1,2,3,4,5,6,7,8} could see https://opensea.io/RareConcurrencies -- and for separate collections therein of some of the preimages, could go to the following links:

https://opensea.io/collection/50-norm-tokens

https://opensea.io/collection/20-norm-tokens

https://opensea.io/collection/10-norm-tokens

https://opensea.io/collection/1-norm-tokens

https://opensea.io/collection/100-norm-tokens

https://opensea.io/collection/200-norm-tokens

https://opensea.io/collection/500-norm-tokens

https://opensea.io/collection/1000-norm-tokens

Please email wolfram-u@wolfram.com with more details, they should be able to help

One of the modes mentioned in the section on AES is GCM yet I cannot find information on this as an option in Encrypt[]. An example (after generating the variable myKey using GenerateSymmetricKey["AES256"]):

Encrypt[myKey, "Now is the time", 
 Method -> Association["BlockMode" -> "CTR"]]

works, but

Encrypt[myKey, "Now is the time", 
 Method -> Association["BlockMode" -> "GCM"]]

Gives

Encrypt::invblockmode: GCM is not a known block mode for this cipher.

Given the properties of the GCM block mode, I would think this is a highly desirable mode to support. Is there some way of getting it to work?

GCM is certainly on our TODO list.

In response to the question, "Why doesn't an MD5 hash provided by Mathematica for a download successfully check using Mathematica?" I thought more about this in the context of the study group and finally "cracked" the problem. In the past, even Wolfram has recommended using OpenSSL (or the like) to compute a hash. I always thought, a hash is a hash is a hash, so why doesn't the hash provided in Mathematica work.

I figured it had to be in the way the files were being treated and that led to the following, which for the first time worked for me: GenerateFileMD5[fileName_String]:=Hash[ReadByteArray[fileName],"MD5","HexString"]

By way of example, the 13.0.1 release came out a couple of days ago. The published MD5 checksum for the MacOS version is 8ba7afa9966ae12bc8abbcb405a1ccd4. Running the code above gives

GenerateFileMD5["~/Downloads/Mathematica_13.0.1_BNDL_MAC_EXP.dmg"]

Out[35]= "8ba7afa9966ae12bc8abbcb405a1ccd4"

Alternatively (and what had to be done in the past), I get the following: openssl md5 ~/Downloads/Mathematica_13.0.1_BNDL_MAC_EXP.dmg MD5(Mathematica_13.0.1_BNDL_MAC_EXP.dmg)= 8ba7afa9966ae12bc8abbcb405a1ccd4 The same answer. Finally, I can quit using OpenSSL and instead use Mathematica to self-check the MD5 signature. From our study group, remember, MD5 is only good to prevent unintentional corruption.

I hope this is helpful to others and becomes the recommended way of using Mathematica to check the Mathematica MD5 hash.

Same with me

A little fun related to today's lesson! try cracking a hashed password: https://rsk0315.github.io/playground/passwordle.html

Another one that is much easier (doesn't involve first trying to find the hash and then the password): https://passwordle.com/

Following the "Hybrid Cryptography, Public Key Certificates" lesson we had on Tuesday 15/02, here is a link to a presentation (incl. slides and video), whose topic is "Secure Communication with TLS" (by Bruce Momjan): https://fosdem.org/2022/schedule/event/security_tls/

In this presentation, actual examples of how this is used in real-life are discussed, including digital certificates for authentication.

We noticed this, too! We'll fix the problem and post when it's redeployed. Thanks for noting it.

We have a problem with the video logging properly. It will be fixed soon.

Hello, thank you for pointing out the logging issue. I have checked with our developer and can confirm that the issue has been fixed. You should be able to refresh your progress tracker and see the video now logged. Please email wolfram-u@wolfram.com if you encounter further issues.

Thanks very much for the reference and the paper! I wonder how much I will need to unlearn about what I think I know about quantum mechanics.

I haven't got today's session link. Can someshare it here please

For those interested in potential effect of quantum computers on modern asymmetric cryptography, an article was published recently where they calculated how many qubits would be needed to break the elliptic curve used in Bitcoin: https://www.schneier.com/blog/archives/2022/02/breaking-245-bit-elliptic-curve-encryption-with-a-quantum-computer.html

I would say so, yes. I'm not much of an expert on quantum physics though, but to understand how these cryptographic algorithms compare to each other in terms of key size vs security I found this paper a while back (by Lenstra, also referenced in the previously linked article) https://www.semanticscholar.org/paper/Key-Lengths-Contribution-to-The-Handbook-of-Lenstra/80d0c05336abbc51d095c1af2ae8143d493beacb

In order to give a visualisation of these numbers (how the bit lengths compare), here are some plots:

• First, the numbers themselves;
• Then, where the bit lengths are in log-scale;
• Finally, inverse of bit lengths.

Yes, having curve order be a prime number p maximizes the number of possible elliptic curve points (it will be p-1). However, there are also many curves used that defined over so-called extension fields modulo p^m or binary fields modulo 2^m, like ed448, ed25519, scet233k1. Binary fields have advantage of more efficient calculations.

Thanks for your response. This will take a bit more thinking on my part!

This "CirclePlus" operation, defined as the addition of two elements (x and y) modulo 5, can be interpreted as the additive law that, together with the set of elements G = {0,1,2,3,4}, provide a representation for the cyclic group Z/5Z (see the explanations that follow in the notebook).

Furthermore, there exists a generator element "g", that is such that, when being "summed" (with the CirclePlus law) together with itself repeatedly, can generate all the elements of the group. The diagram that follows is the so-called "cycle graph" for this group Z/5G : it basically gives a pictorial representation of the statement about the existence of the generator element from above. Each edge in that graph, represents one iteration of such sum with the generator.

The question is being edited. Thanks to Doug and Hakan for their very helpful comments.

Thank you, Doug. Good points. Still,

(.) I can make up some scenarios where one needs to memorize a key. Besides, the correspondence between key, cipher, and plain text is not necessary so direct.

(.) As to the second part, I used sequences of all 1s or 0s just as an example. As a memorable one, I can use a sequence taken from the phone numbers or plate numbers, or addresses.

The question stays. When you say "more random", what does it mean? In the example with the coins, which sequence of the equally probable outcomes is "more random"?

Put differently, you can discuss the randomness of a large sample of sequences. You do not usually quantify the randomness of one particular sequence*.
------------------------------------------------------------------------------------------------- * As opposed, for instance, to the subset of sequences with m and n occurrences of 0 and 1 (whose probability should converge to the Binomial distribution if PRNG is good).

There are some statistical tests to determine if a sequence "looks random" and are used to test pseudo random generators. Dariia talked about this in the 4th session "Measuring Security, Randomness and Pseudorandomness".

Also, see my post above ("Test statistics - Week 1 Review quiz/assignment") which also shows some of the statistical tests of bit sequences..

Michael, for uses when you need to memorize the key/password and still have an actual encryption key be random, there is a set of cryptographic algorithms called Key Derivation Functions (see GenerateDerivedKey in Wolfram, for instance). There will also be a relevant lesson on Wednesday!

Solve[Mod[9 x,23,x]==1,x]

Please note, that the 3-argument form of Mod means, according to the documentation,

Mod[m, n, d] uses an offset d.

Using the Integers option give some answers:

Solve[Mod[9 x, 23, x] == 1, x, Integers]
Reduce[Mod[9 x, 23, x] == 1, x, Integers]

{{x -> -5}}
x == -5

And:

Solve[Mod[9 x, 23] == 1, x, Integers]

{{x -> ConditionalExpression[
    18 + 23 ConditionalExpression[1, \[Placeholder]], 
    ConditionalExpression[1, \[Placeholder]] \[Element] Integers]}}

It's (the field of) Integers (with 's'), and this will be the same as Z.

You can restrict the value of x via an extra constraint:

Solve[{Mod[9 x, 23] == 1, 0 <= x < 23}, x, Integers]
Reduce[{Mod[9 x, 23] == 1, 0 <= x < 23}, x, Integers]

{{x -> 18}}
x == 18

At the bottom of the course page, the last entry is "Track My Progress." When clicked, it lists two conditions for successful completion of the course:

    "Earn your certificate of course completion by watching 25 course videos and ..."

However, it gives me, and I guess others, ZERO credit for watching the videos during Dariia's lectures. I assume this feature is meant for the future course takers, not for the current cohort. Please clarify.

I did not check Doug's suggestion (first goes first :) ) but Stinson's book mentioned by Hakan looks impressive. Its 1995 edition is available at https://ia803405.us.archive.org/19/items/pdfy-eAEdqcELZKUUU733/Cryptography%20Theory%20And%20Practice%20-%20Douglas%20Stinson.pdf. Apparently, it is close if not identical (Hakan, pls comment if you can) to the aforementioned 1999 edition.

The two resources that gave me a better understanding of elliptical curves in Mathematica

"Elliptic Curve Cryptography with Mathematica" by Jouko Teeriaho (attached )

and a better understanding of the algorithms associated with elliptical curves at

Elliptic Curve Cryptography: a gentle introduction by Andrea Corbellini

I found the visual tool very handy

Attachments:

Elliptic Curve C...pdf

Thanks, Doug. Great links, very "hand-on"! Best. M

Doug,

Your link to the pdf file (notebook?) by Jouko Teeriaho does not work. Could you re-post it, please?

Thanks, Zbigniew

Doug, Thanks for your quick response. I really appreciate it. And the file indeed looks like a great read--I am delving right into it. Cheers, Zbigniew

Just in case anyone is interested, Eric W. Weisstein's notebook http://mathworld.wolfram.com/notebooks/NumberTheory/EllipticCurve.nb in modern notations is simply (show its main part):

In[3]:= curves = {x^3 - 1, x^3 + 1, x^3 - 3 x + 3, x^3 - 4 x, x^3 - x};

In[22]:= GraphicsGrid[{ContourPlot[y^2 == #, {x, -3, 3}, {y, -3, 3}, ContourStyle -> {Red, Thick}] & /@ curves}]

There is no need to install the packages, GraphicsImplicitPlot and GraphicsColors, and some functions are now (13 years later) outdated.

Earlier this week I took Quiz 1-4 without any problems. Yesterday I tried Quiz 5 and got the same result as you, i.e. only 0-scores. After quite much of reloading the Quiz page, changing some answer and submitting the answers, it finally worked and I got a proper score.

(I reported this to wolfram-u@wolfram.com so they should be aware of the problem.)

I did what you suggested but did not work, I am still awaiting contact from the email I sent to wolfram-u@wolfram.com

Given the number of times Claude Shannon's name has come up during the study group, I thought that SG participants might want to learn more about this amazing man. I thought he was brilliant before joining the study group and my admiration has only increased over the past two weeks.

A Mind at Play: How Claude Shannon Invented the Information Age Kindle Edition by Jimmy Soni (Author), Rob Goodman (Author) In their second collaboration, biographers Jimmy Soni and Rob Goodman present the story of Claude Shannon—one of the foremost intellects of the twentieth century and the architect of the Information Age, whose insights stand behind every computer built, email sent, video streamed, and webpage loaded. Claude Shannon was a groundbreaking polymath, a brilliant tinkerer, and a digital pioneer. He constructed the first wearable computer, outfoxed Vegas casinos, and built juggling robots. He also wrote the seminal text of the digital revolution, which has been called “the Magna Carta of the Information Age.” In this elegantly written, exhaustively researched biography, Soni and Goodman reveal Claude Shannon’s full story for the first time. With unique access to Shannon’s family and friends, A Mind at Play brings this singular innovator and always playful genius to life.

for the vigenere question I have

h e l l o w o r l d 08 05 12 12 15 23 15 18 12 04

m y k e y m y k e y 13 25 11 05 25 13 25 11 05 25

Mod[8+13,26] = 21 Mod[5+25,26] = 04 Mod[12+11,26] = 23 Mod[12+05,26] = 17 Mod[15+25,26] = 14 Mod[23+13,26] = 10 Mod[15+25,26] = 14 Mod[18+11,26] = 03 Mod[12+05,26] = 17 Mod[04+25,26] = 03

U D W Q N I N C Q X 21 4 23 17 14 10 14 03 17 03

Using the Vigenère cipher, what is the encrypted form of the message “helloworld” using the key “mykey”?

tcvpmimbpb

khoorzruog

uryybjbeyq

->None of the above

Shows a wrong answer for quiz 1, am I off base on this? Thanks for a good clue Luke and a really great course, I could do another month of this class!

This seemed a little specific for the community discussion, but if it is apropos I am happy to stand corrected of course.

Also thanks for the proof around 30min. It is quite nice and easy, and lends itself well to a discussion of "confusion" from your suggested article. Here is another notation using Fold:

FeistelForm[kn_] := {#[[2]], Xor[#[[1]], F[#[[2]], kn]]} &
FoldList[#2@#1 &, {L, R}, {
    FeistelForm[k1], FeistelForm[k2], FeistelForm[k3], Reverse,
    FeistelForm[k3], FeistelForm[k2], FeistelForm[k1], Reverse
    }] ;
SameQ[%[[1]], %[[-1]]]
Out[] = True

Let's try and make this a little easier for Physicists (or former) by assuming that $F$ is just addition, then the naive form reduces to linear algebra:

NaiveFeistelForm[kn_] := {{0, 1}, {1, 1}} . # + {0, F[kn]} &
FoldList[#2@#1 &, {L, R}, {
    NaiveFeistelForm[k1], NaiveFeistelForm[k2], NaiveFeistelForm[k3], 
    Reverse,
    NaiveFeistelForm[k3], NaiveFeistelForm[k2], NaiveFeistelForm[k1], 
    Reverse
    }] /. {_Integer?EvenQ -> 0, _Integer?OddQ -> 1};
SameQ[%[[1]], %[[-1]]]
Out[]=True

What happens here is basically a nesting $g \cdot( \ldots( g\cdot(g\cdot s + p_1) + p_2 ) \ldots ) + p_n $, and it's easy to see if distributive holds we get $g^n \cdot s +P$ where $s$ is signal, $P$ a summed pad, and mixing matrix $g$ satisfies $g^3=Id$. This is the same problem I mentioned previously, where Feistel scheme essentially reduces to a one time pad. However if the pair of operations $(\cdot,+)$ do not allow distributive property, then the nested form above might actually be a decent characterization of what is meant (loosely) by "Feistel Scheme".

There is one alternative, applying the pad before the mixing: $g \cdot( \ldots( g\cdot(g\cdot (s + p_1) + p_2 ) \ldots + p_n) $. In this case distributive does not hold if $g\cdot (s + p_1) \neq g\cdot s +g\cdot p_1 $, which is what we want to fix the previous algorithm. Start by generating test data:

SeedRandom["confusion"];
randPad = RandomInteger[{0, 4}, 32];
randMessage = RandomInteger[{0, 4}, 32];

And weakly prove (in terms of test data) distributive holds in the previous case:

SameQ[ Flatten[ Mod[ForwardMix . Partition[Plus[randPad, randMessage], 8], 5]],
 Flatten[Mod[Plus[ ForwardMix . Partition[randPad, 8],
    ForwardMix . Partition[randMessage, 8]], 5]]] 
Out[]=True

This is what we don't want, so we need to add new Addition and Subtraction functions (the idea is taken from Dariia's suggested reference above):

BoxSubtract[dat1_, dat2_, part_, base_] :=With[{ints = (FromDigits[#, base] & /@ 
        Partition[#, part]) & /@ {dat1, dat2}}, Flatten[
   IntegerDigits[#, base, part] & /@ Mod[Subtract @@ ints, base^part]]]

BoxPlus[dat1_, dat2_, part_, base_] :=  With[{ints = (FromDigits[#, base] & /@ 
        Partition[#, part]) & /@ {dat1, dat2}}, Flatten[
   IntegerDigits[#, base, part] & /@ Mod[Plus @@ ints, base^part]]]

(* test inverse property *)
SameQ[BoxSubtract[BoxPlus[randPad, randMessage, 8, 5], randPad, 8, 5], randMessage] 
Out[]=True

Again here is a proof that distributive doesn't hold:

(* not distributive *)
SameQ[  Flatten[ Mod[ForwardMix . Partition[BoxPlus[randPad, randMessage], 8], 5]],
 Flatten[Mod[BoxPlus[  ForwardMix . Partition[randPad, 8],
    ForwardMix . Partition[randMessage, 8]], 5]]]
Out[]=False

Then our Encode / Decode functions need only minor modification, replacing Plus and Subtract for BoxPlus and BoxSubtract:

EncodeRound[sig_, AGmat_] := Flatten[
    Mod[ForwardMix . Partition[BoxPlus[sig, AGmat, 8, 5], 8], 5]]

DecodeRound[sig_, AGmat_] := Mod[BoxSubtract[ReplaceAll[
        Mod[Flatten[ReverseMix . Partition[sig, 8]], 5], Div4], AGmat,
    8, 5], 5]

Using these updated functions, we can produce another set of encrypts:

These are possibly better than the previous set since we are doing a little more than just padding, but the run statistics really don't look any better. I am still skeptical--What exactly do we gain by requiring non-distributive property? Is one data set easier to decrypt than another?

I think that the non-distributive property must be an important defining part of what makes a Feistel Cipher, but I don't yet completely understand the theory why. Anyone else, agree / disagree? Thoughts?

It's always fun to hear about these kind of discussions, especially about how a function should be named or which parameters / their orders should be, in order to be the most general and not have to be changed in the very near future of its introduction.

Question for the community: Should hash values calculated with the same algorithms but on different platforms agree?

I tried comparing the hash digest for a simple text string ("abcdefg") calculated with Mathematica and calculated with an online calculator https://www.fileformat.info/tool/hash.htm . The notebook is attached. I tried a few different hash algorithms but the hash digests did not agree with the Mathematica digest.

Attachments:

HashExperiment.nb

Thanks! The daily study group is very interesting and informative.

After watching the last session on Feistel schemes and reading some of Hakan's code, it seems like we have a pro-binary bias sneaking in here. The overall theme of this post is to say that cryptography still works with more than two symbols (or without self-inverse properties), but the implementation may not be as neat and simple. For example, Dariia's transformation analysis of Feistel scheme might not apply at higher radix, if XOR is generalized to addition modulo base $b>2$. As long as implementations still run fast, added complexity can even serve a purpose relative to the adversary.

Here is some encrypted data, which I claim is the output of a sort-of Feistel Cipher:

Repeated Encryption of a length 32 message over 4 symbols

To the eye, it looks random, but we need to do testing. Normality does not imply randomness, but it is a necessary condition. We can easily check run lengths in base 5 (the encrypt base is one higher than the message base), but first let's look at base 10 encoding:

encodes =  Partition[Partition[#, 4][[All, 1]] & /@ Transpose[ReplaceAll[
       Round[ImageData[Import["~/Work/Cryptography/encrypts.png"]]],
       {{1, 0, 0} -> 2, {0, 1, 0} -> 3, {0, 0, 1} -> 1, {1, 1, 1} -> 
         0, {1, 1, 0} -> 4}]], 4][[All, 1]];

Row[Show[#, ImageSize -> 300] & /@ {Histogram[
    FromDigits[#, 5] & /@ encodes, 10],
   ListLogPlot[FromDigits[#, 5] & /@ encodes]}, Spacer[20]]

Decently flat between $10^{21}$ and $10^{22}$. Now here are run length tests, which I have written in a base-dependent graphical form:

TestNormalListPlot[data_, runLen_, base_] := ListPlot[
  Tally[FromDigits[#, base] & /@ Flatten[
     Partition[#, runLen, 1, 1] & /@ data, 1]],
  PlotRange -> {0, Automatic}]

TestNormalHistogram[data_, runLen_, base_] := Histogram[
  Tally[FromDigits[#, base] & /@ Flatten[
      Partition[#, runLen, 1, 1] & /@ data, 1]][[All, 2]],
  PlotRange -> {{0, Automatic}, {0, Automatic}}]

And the output data looks Gaussian distributed as is expected for random inputs:

TableForm[Partition[Show[
     TestNormalListPlot[encodes, #, 5],
     ImageSize -> 300] & /@ Range[4], 2]]

TableForm[Partition[Show[
     TestNormalHistogram[encodes, #, 5],
     ImageSize -> 300] & /@ Range[4], 2]]

The purpose of the entire battery of diehard tests is to look beyond normalcy for other hints of randomness. Diehard is considered state of the art in practice, but I've heard that machine learning can sometimes do better finding bits of unexpected order. So I'll leave the question open, does anyone have a test on the data above that is predictive of at least one digit (without peeping at the keys, which are online somewhere)?

We definitely can't look at an Feistel Cipher output and identify it as such. For the output above, we probably can't rule out that it follows from a Feistel cipher (again, unless someone starts predicting digits). So instead we have to go back to algorithm analysis. Dariia's transformation analysis gives us a nice place to start--if we just ignore the issue about S-Boxes. I don't know anyone else's opinion, but Daniel Bernstein's argument against S-Boxes has influenced my thinking that "S-Boxes are just mathematical functions with some certain properties, and they may not always be necessary".

Now, Dariia has emphasized self-inverse as a defining property of Feistel cipher, but I disagree by saying that the self-inverse property is a result of choosing $\bigoplus$ as Addition modulo 2, and choosing a parity permutation group, for which group action is self inverse. If another choice is made, say addition modulo 5 with cyclic permutation of order 4, then the parity symmetry is broken and an inverse round function is needed. Such an algorithm keeps a reversible key-schedule, and may mix blocks more effectively, thus reducing need for round function $F$ to be overly complex.

Here again is the code for producing encrypts above, and for decrypting them when the corresponding secret keys are known. First an apparently(?) almost pseudo-random number generator (thanks again Larva Labs!):

ONE = 4294967296;
SIZE = 32; HALFSIZE = 16;

xyz[ind_, aVal_] := With[{x0 = 2*(ind - HALFSIZE) + 1},
    x0*aVal^2 (*hacked to force overflow, no sym*)]

v[x_, y_, z_, mod_] := With[{v0 = Mod[Floor[
            If[# > 2^255 - 1, Mod[(# - 2^256)/ONE + 1, 2^256],
                  #/ONE] &@Mod[x*y*z, 2^256]], mod]},
    If[v0 < 5, v0, 0]]

AutoGlyphM1D[aVal_] := With[{mod = Mod[aVal, 11] + 5},
    Outer[v[xyz[#1, aVal], 1, 1, mod] &,
      Range[0, SIZE - 1], 1]]

Next the round functions, key iterator, etc. : : :

ItKeys[key_, nInd_] := 
  Map[Mod[Floor[key Pi^#], 2^160] &, Range[0, nInd - 1]]

(* Eigenvectors of CyclicG4 *)
ForwardMix = {
   {1, 1, 1, 1},
      {1, -1, 1, -1},
      {1, 0, -1, 0},
      {0, -1, 0, 1}};

ReverseMix = 4 Inverse[ForwardMix];

Div2 = MapThread[Rule, {Mod[2 Range[0, 4], 5], Range[0, 4]}];
Div4 = MapThread[Rule, {Mod[4 Range[0, 4], 5], Range[0, 4]}];

EncodeRound[sig_, AGmat_] := Flatten[
    Mod[ForwardMix . Partition[Plus[sig, AGmat], 8], 5]]

DecodeRound[sig_, AGmat_] := Mod[Subtract[ReplaceAll[
        Mod[Flatten[ReverseMix . Partition[sig, 8]], 5], Div4], 
   AGmat], 5]

Char4Encode[sig_, key0_, recd_] := Fold[
    EncodeRound[#1, AutoGlyphM1D[#2]] &,
    sig, ItKeys[key0, recd]]

Char4Decode[Crypted_, key0_, recd_] := Fold[
    DecodeRound[#1, AutoGlyphM1D[#2]] &,
    Crypted, Reverse@ItKeys[key0, recd]]

And the call to decrypt is:

AbsoluteTiming[  decodes =  MapThread[Char4Decode[#1, #2, 4] &, 
       {encodes, SecretKeys}];]
 Union[Style[ StringJoin[
          FromCharacterCode[FromDigits[#, 4]] & /@ Partition[#, 8]], 
    Bold,  16] & /@ decodes]
Out[]= l.t. 1s
Out[]={????}

So what are we still arguing about? Well, it may be possible to choose a self-inverse permutation, starting from something like:

Mod[# . # &@(ForwardMix . ForwardMix), 5] /. Div2
Out[]= Identity Matrix 4

And maybe if we applied more creativity and / or chose an even radix, we could find an operator such as $x \bigoplus y=x+b/2\times y \mod b$ which would be self inverse for radix $b$, I don't know, and don't know if we should spend time on that question.

So, in the end, Dariia and the rest of the experts might be right, self-inverse could be a necessary property of the Feistel Scheme. In that case, how to categorize the encrypt / decrypt algorithm presented above? Clearly we can change to whatever base, and use whatever permutation group representations so long as the inverse details work out. Does anyone have a reference to anything like this in the literature?

The confusion property on P. 31 looks good. One weakness of the above algorithm is that linearity of encode rounds ensures after four rounds that the ciphertext is permuted back to its original place with a factor 2, not ideal. In that sense, my simple algorithm looks more like a one time pad. However, I could also argue that Feistel cipher is just a clever way to apply one time pads. Back to the drawing board... maybe a permutation over all 32 indices?

Nice!

Did you look at NIST's "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications" (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-22r1a.pdf) that Dariia mentioned in the session about Randomness/Pseudorandomness? It contains a Fourier related test (section "2.6 Discrete Fourier Transform (Spectral) Test") and a lot of other statistical tests. Though I don't find anything about your other test, the QuantilePlot Analysis.

The notebook "09_Randomness and pseudorandomness.nb" has some other recommended documents as well (in the Further Reading section)..

Here is my write up on Dariia's Weekend "assignment" (attached).

Attachments:

Test statistics.nb

Thanks, Dariia!

I'll check out those more complex tests. Though I do like to implement stuff. :-)

Questions for Dariia (or other experts): Is there a list where WFR covers diehard tests, and are we missing any? What does it really mean if an encrypt fails diehard? I'm thinking that a combination of steganography with cryptography could fail diehard and still be decently hard metal. For example, did anyone decode the fake NFTs that I made for the "happy new years" contest?

Wolfram does not support UTF16 encoding unfortunately

Hi Hermes

Wow , that is impressive . I will play around with it to test it but it looks great and a candidate for the repository.

There does not seem to be a textbook of "Encryption with Mathematica" so I got the next best thing, "Encryption with python " books and as the functions are similar it is quite easy to convert from python hashlib library to the Wolfram Hash Function. The textbooks I have consulted all use the Windows NTLM Microsoft authentication protocol that uses UTF-16 Little Endian encoding as examples. (Maybe there is a little bias by Wolfram to Mac and Linux against Windows :) )

Brad, thanks for the link of your analysis. I'll read it more carefully and also the "SHA-1 is a Shambles" article you cited (https://sha-mbles.github.io/ ).

A related idea is to search for the smallest hash collisions for the two weak hash functions (CRC32 and Adler32) and use all possible strings of a certain size. Unfortunately, for the generated wordlists that I could test, there wasn't any hash collisions which surprised me a little. Anyway, here's the idea and the code.

Let's assume that we use words with strings of the characters [a-zA-Z0-9] and generate all possible strings up to a certain length, i.e. size = 3 generates all possible strings of length 1, 2, and 3.

Here's the alphabet and 30 random samples:

alpha = Flatten[{CharacterRange["a", "z"], CharacterRange["A", "Z"], 
   CharacterRange["0", "9"]}];

RandomSample[
 Table[StringJoin[#] & /@ Tuples[alpha, n], {n, 1, 3}] // Flatten, 30]

{"oEg", "LMZ", "j3n", "GDY", "dUe", "7ma", "Z5x", "jtb", "6OI", \
"HdL", "EzE", "VMY", "OYM", "p7Z", "PNg", "Vqz", "obw", "Kyj", "OUi", \
"pda", "LwI", "S2A", "4KO", "Ah0", "VsX", "XI4", "ZiC", "tRE", "EMv", \
"fc3"}

We reuse some of the functions from the original notebook:

crc32[word_] := Hash[word, "CRC32", "HexString"]
adler32[word_] := Hash[word, "Adler32", "HexString"]

listCollisions2[words_, fun_] := 
 Module[{hashList, counts, hashMap, collisions},
  hashList = fun[#] & /@ words;
  If[Length[hashList] != Length[words],
   counts = Counts[hashList];
   hashMap = AssociationThread[words -> hashList];
   collisions = Keys@Select[counts, # > 1 &];
   Table[Select[hashMap, # == c & ], {c, collisions}] ,

   {} (* else: no collisions *)
   ]
  ]

As mentioned above, we don't found any hash collisions for CRC32 or Adler32 for sizes up to 4:

Table[{n, listCollisions2[generateWords[n], crc32]}, {n, 1, 4}] // AbsoluteTiming
{25.0142, {{1, {}}, {2, {}}, {3, {}}, {4, {}}}}

Table[{n, listCollisions2[generateWords[n], adler32]}, {n, 1, 4}] // AbsoluteTiming
{25.9066, {{1, {}}, {2, {}}, {3, {}}, {4, {}}}}

One major problem with this approach is that the size of wordlists increases very fast and soon be forbiddingly large:

Table[{n, Length[generateWords[n]]}, {n, 1, 4}] // TableForm

{
 {1, 62},
 {2, 3 906},
 {3, 242 234},
 {4, 150 18 570}
}

For size 5, I couldn't even generate the wordlist (got the error "No more memory available. Mathematica kernel has shut down"), but using WL's excellent FindSequenceFunction we can at least estimate the sizes of the wordlists for larger sizes:

FindSequenceFunction[{62, 3906, 242234, 15018570}]
{#, %[#]} & /@ Range[1, 10] // TableForm

which outputs

62/61 (-1 + 62^#1) &
{
 {1, 62},
 {2, 3906},
 {3, 242234},
 {4, 15018570},
 {5, 931151402},
 {6, 57731386986},
 {7, 3579345993194},
 {8, 221919451578090},
 {9, 13759005997841642},
 {10, 853058371866181866}
}

Thus, generateWords[5] would give a wordlist of 931 151 402 words.

Update:

Perhaps it's not that surprising that there are no hash conflicts for Adler32. Here are some of the words and their Adler32 hashes for the size 4 generated words, i.e. the hashes are distinct and just incrementing from the last (two counters) and are in order.

Short[{#, adler32[#]} & /@ generateWords[4], 20]

{{"a", "00620062"}, {"b", "00630063"}, {"c", "00640064"}, {"d", 
  "00650065"}, {"e", "00660066"}, {"f", "00670067"}, {"g", 
  "00680068"}, {"h", "00690069"}, {"i", "006a006a"}, {"j", 
  "006b006b"}, {"k", "006c006c"}, {"l", "006d006d"}, {"m", 
  "006e006e"}, {"n", "006f006f"}, {"o", "00700070"}, {"p", 
  "00710071"}, {"q", "00720072"}, {"r", "00730073"}, {"s", 
  "00740074"}, {"t", "00750075"}, {"u", "00760076"}, {"v", 
  "00770077"}, {"w", "00780078"}, {"x", "00790079"}, {"y", 
  "007a007a"}, {"z", "007b007b"}, {"A", "00420042"}, {"B", 
  "00430043"}, {"C", "00440044"}, {"D", "00450045"}, {"E", 
  "00460046"}, {"F", "00470047"}, <<15018506>>, {"999E", 
  "024a00f1"}, {"999F", "024b00f2"}, {"999G", "024c00f3"}, {"999H", 
  "024d00f4"}, {"999I", "024e00f5"}, {"999J", "024f00f6"}, {"999K", 
  "025000f7"}, {"999L", "025100f8"}, {"999M", "025200f9"}, {"999N", 
  "025300fa"}, {"999O", "025400fb"}, {"999P", "025500fc"}, {"999Q", 
  "025600fd"}, {"999R", "025700fe"}, {"999S", "025800ff"}, {"999T", 
  "02590100"}, {"999U", "025a0101"}, {"999V", "025b0102"}, {"999W", 
  "025c0103"}, {"999X", "025d0104"}, {"999Y", "025e0105"}, {"999Z", 
  "025f0106"}, {"9990", "023500dc"}, {"9991", "023600dd"}, {"9992", 
  "023700de"}, {"9993", "023800df"}, {"9994", "023900e0"}, {"9995", 
  "023a00e1"}, {"9996", "023b00e2"}, {"9997", "023c00e3"}, {"9998", 
  "023d00e4"}, {"9999", "023e00e5"}}

Testing with some longer words and it use the same principle of two counters:

{#, adler32[#]} & /@ {"aaaaa", "aaaab", "aaaac", "aaaaaaaaaaa", 
  "aaaaaaaaaab",
  "aaaaaaaaaaaaaaaaaaa", "aaaaaaaaaaaaaaaaaab"}

{{"aaaaa", "05b401e6"}, {"aaaab", "05b501e7"}, {"aaaac", 
  "05b601e8"}, {"aaaaaaaaaaa", "190d042c"}, {"aaaaaaaaaab", 
  "190e042d"}, {"aaaaaaaaaaaaaaaaaaa", 
  "48110734"}, {"aaaaaaaaaaaaaaaaaab", "48120735"}}

The hashes for CRC32 is much more random like:

Short[{#, crc32[#]} & /@ generateWords[4], 20]

{{"a", "e8b7be43"}, {"b", "71beeff9"}, {"c", "06b9df6f"}, {"d", 
  "98dd4acc"}, {"e", "efda7a5a"}, {"f", "76d32be0"}, {"g", 
  "01d41b76"}, {"h", "916b06e7"}, {"i", "e66c3671"}, {"j", 
  "7f6567cb"}, {"k", "0862575d"}, {"l", "9606c2fe"}, {"m", 
  "e101f268"}, {"n", "7808a3d2"}, {"o", "0f0f9344"}, {"p", 
  "82079eb1"}, {"q", "f500ae27"}, {"r", "6c09ff9d"}, {"s", 
  "1b0ecf0b"}, {"t", "856a5aa8"}, {"u", "f26d6a3e"}, {"v", 
  "6b643b84"}, {"w", "1c630b12"}, {"x", "8cdc1683"}, {"y", 
  "fbdb2615"}, {"z", "62d277af"}, {"A", "d3d99e8b"}, {"B", 
  "4ad0cf31"}, {"C", "3dd7ffa7"}, {"D", "a3b36a04"}, {"E", 
  "d4b45a92"}, {"F", "4dbd0b28"}, <<15018506>>, {"999E", 
  "8fef8e8d"}, {"999F", "16e6df37"}, {"999G", "61e1efa1"}, {"999H", 
  "f15ef230"}, {"999I", "8659c2a6"}, {"999J", "1f50931c"}, {"999K", 
  "6857a38a"}, {"999L", "f6333629"}, {"999M", "813406bf"}, {"999N", 
  "183d5705"}, {"999O", "6f3a6793"}, {"999P", "e2326a66"}, {"999Q", 
  "95355af0"}, {"999R", "0c3c0b4a"}, {"999S", "7b3b3bdc"}, {"999T", 
  "e55fae7f"}, {"999U", "92589ee9"}, {"999V", "0b51cf53"}, {"999W", 
  "7c56ffc5"}, {"999X", "ece9e254"}, {"999Y", "9beed2c2"}, {"999Z", 
  "02e78378"}, {"9990", "af800b3e"}, {"9991", "d8873ba8"}, {"9992", 
  "418e6a12"}, {"9993", "36895a84"}, {"9994", "a8edcf27"}, {"9995", 
  "dfeaffb1"}, {"9996", "46e3ae0b"}, {"9997", "31e49e9d"}, {"9998", 
  "a15b830c"}, {"9999", "d65cb39a"}}

This group might be interested in a post a made a few months ago Twitter steganography.

The interesting use for steganography may be to send encrypted information attached to Twitter photos. As a communication channel it might be very hard to monitor and notice when encrypted information was actually being transmitted.

Initialization cell to introduce the abbreviation seq ;-)

a = 65539; b = 0; m = 2^31; LCG[seed_Integer] := Mod[a*seed + b, m]; seq = NestList[LCG, 1, 10]

Hello Hakan,

If you "help" WL by specifying the bb = 2^31 and the shift bb = 0, you will get an answer:

Solve[{seq[[2]] == Mod[aa*seq[[1]] + 0, 2^31]}, aa \[Element] 
Integers]

Even if you omit the shift bb = 0, you get an answer.

Solve[{seq[[2]] == Mod[aa*seq[[1]] + bb, 2^31]}, {aa, bb} \[Element] 
  Integers]

On the other hand, if you ask for mm, i.e.

Solve[{seq[[2]] == Mod[aa*seq[[1]] + 0, mm]}, {aa, mm} \[Element] 
  Integers]

your error/warning message will be reproduced. The same happens when you try the toy example

Solve[1 == Mod[15, x], x]

(Edit: Note, that Solve[1 == Mod[15, x], x, Integers] works, and likewise Solve[2022 == Mod[65539, x], x, Integers]. \Edit)

But you can get around that by running this:

Table[{k -> 
   Solve[{seq[[2]] == Mod[aa*seq[[1]] + 0, 2^k]}, {aa} \[Element] 
     Integers]}, {k, 1, 40}]

By doing so, you get a whole bunch of solutions....

But I think we're moving from the Crypto topic to modulo computation now....

PS: Sorry I didn't post the output here, because the conditional expressions make the result very unreadable here...

This question may be more related to a future crypto lesson.

I was toying around with encrypting/decrypting data (using Mathematica 12.1 functions) with DES, using the "Electronic Cookbook" (ECB) block mode, and was surprised by some obtained results, see below. I would like to know the reasons of such behaviour, as well as whether it's possible to know and/or control what data padding is being used by default, in these settings?

For an (a priori) empty byte array, the encrypted data length is much longer than for a one-byte array:

In[1]:= Encrypt[desKeyECB, ByteArray[{}]]["Data"] // Normal
Out[1]= {238,110,253,99,228,27,8,224,142,28,87,146,1,47,70,240,237,69,176,169,25,122,166,240}

but:

In[2]:= Encrypt[desKeyECB, ByteArray[{0}]]["Data"] // Normal
Out[2]= {177,216,132,168,6,11,203,72}

which is shorter.

Finally, while it is known that DES works on 64-bit data chunks, I noticed that the encrypted data's length will increase already the 56-bit

7-byte (i.e. 56-bit)-long data: gives an encrypted block of 64 bits:

In[3]:= Encrypt[desKeyECB, ByteArray[{0, 1, 2, 3, 4, 5, 6}]]["Data"] // Normal
Out[3]= {62,54,162,174,211,50,208,182}

However, 8-byte (i.e. 64-bit)-long data would give a longer encrypted block of 2 x 64 bits:

In[4]:= Encrypt[desKeyECB, ByteArray[{0, 1, 2, 3, 4, 5, 6, 7}]]["Data"] // Normal
Out[4]= {83,131,254,213,181,242,11,15,151,186,160,29,255,217,246,70}

Interestingly, the last 8 bytes in the example above appear to "encode" an empty byte array somehow:

In[5]:= Decrypt[desKeyECB, ByteArray@{151, 186, 160, 29, 255, 217, 246, 70}]
Out[5]= {}

But the empty byte array encrypts differently (see In[1] above). Finally, modifying one of these 8 bytes in In[5] would make Decrypt[] fail. Why is that so? Does this padding also contain some sort of checksum information?

Hermes, I'm not sure what I'm doing wrong, but copying your In[1] statement doesn't work. In your post, as in my attached notebook, the object desKeyECB is marked in blue, meaning Mathematica doesn't understand it. Are you missing a definition of this object in the post? Please clarify?

As a question/suggestion: isn't it common to define the term "information security system" for the set of properties i.e. confidentiality, authentication, data integrity, and non-repudiation.

A longer list. DictionaryWordQ has more words than WordList.

WordList[] // 
AssociationMap[ResourceFunction["CaesarCipher"][#, 3] &] // 
Select[DictionaryWordQ]

The SIGSALY used the heat of giant vacuum tubes as a source of noise, but I've also come across how-to guides for using a reverse-biased zener diode to produce "shot noise", apparently something to do with total, natural randomness of quantum tunneling, don't ask me!

[LINK] A Fast, Cheap, High-Entropy Source for IoT Devices

Thanks for mentioning this. It is possible to "deplete the entropy pool" when doing more business than usual, so HWRNG are worthwhile "weird machines", which could be studied in their own right. How do you think graphene sheets could / should be adapted to this purpose? : :

Vacuum tubes can still be used for some fun experiments on the photoelectric effect, or if you have excess medical grade equipment, possibly for making Geiger counters.

However, as you've said, much of more recent technology has already shifted toward diodes and laser diodes, which are also incredible little devices for any hobbyist's citizen lab. Have Fun! --Brad

Common words appearing as cypher texts of common words when using Caesar Cyphers

With[{
  alpha = ToUpperCase[Alphabet[]],
  enCommon = Select[
    Union[ToUpperCase[WordList[]]],
    Complement[Characters[#], alpha] == {} &]},
 SortBy[
  Table[
   shift -> Intersection[
     enCommon,
     StringReplace[enCommon, 
      Thread[Rule[alpha, RotateLeft[alpha, shift]]]]
     ],
   {shift, 25}],
  Length[Last[#]] &]]

{5 -> {"FIE", "FIT", "IT", "ITS", "KNEE", "PH", "STY", "UM", "YA"}, 
 21 -> {"ADO", "ADZ", "DO", "DON", "FIZZ", "KC", "NOT", "PH", "TV"}, 
 2 -> {"CUR", "DAG", "ETA", "GAG", "GO", "IQ", "KEG", "ME", "MY", 
   "NAG", "OW", "TAG", "TWO", "URGE"}, 
 24 -> {"ASP", "BYE", "CRY", "EM", "EYE", "GO", "ICE", "KC", "KW", 
   "LYE", "MU", "RUM", "RYE", "SPEC"}, 
 1 -> {"BE", "BEE", "BIB", "BY", "DIBS", "EVE", "FOE", "IF", "IN", 
   "JUT", "KPH", "OFF", "PEE", "PI", "PIN", "PIP", "SIP", "TI", "UFO",
    "UP"}, 
 25 -> {"AD", "ADD", "AHA", "AX", "CHAR", "DUD", "END", "HE", "HM", 
   "ITS", "JOG", "NEE", "ODD", "OH", "OHM", "OHO", "RHO", "SH", "TEN",
    "TO"}, 
 9 -> {"AN", "ANY", "ARENA", "ARK", "ARM", "BRA", "BRAN", "BUNNY", 
   "BURY", "BYRE", "CANT", "CARP", "CRY", "DB", "KHAN", "LARK", "NAN",
    "NAP", "NUT", "PRAM", "RAT", "RUT", "TRY", "URN", "WRY"}, 
 17 -> {"BYRE", "CRIB", "ELK", "ERE", "ERG", "GIRD", "ILK", "IRK", 
   "KIP", "LIE", "NIP", "RE", "REP", "RIB", "RID", "RIVER", "SIR", 
   "SIRE", "SLEEP", "SLIP", "SPIV", "TIP", "TREK", "TRIG", "US"}, 
 11 -> {"ALE", "ALTO", "APE", "AS", "AT", "DALE", "DATE", "DAZE", 
   "DAZED", "DEFY", "ELF", "ELM", "ESPY", "ETA", "EYE", "FA", "IT", 
   "LAP", "LO", "LOO", "LYE", "PI", "SPA", "SPY", "STOP", "TO", "YES",
    "ZOO"}, 
 15 -> {"AD", "ADD", "ANT", "APE", "EX", "HEN", "HEP", "HIDE", "ID", 
   "NTH", "ODD", "PAID", "PAT", "PET", "PH", "PI", "SPAT", "SPIT", 
   "SPOT", "SPOTS", "STUN", "TAB", "TAU", "THEN", "TIP", "TNT", "UP", 
   "XI"}, 
 3 -> {"DOE", "DOS", "DUN", "EH", "ERA", "ERE", "ERG", "ERR", "FROG", 
   "GRUB", "HA", "HOP", "HUH", "ID", "IRE", "IRON", "KHZ", "LOO", 
   "ODE", "ORE", "PH", "PLOW", "PROW", "RUE", "SHH", "SHOW", "SHUN", 
   "SOB", "SUB"}, 
 23 -> {"ALB", "ALP", "ARK", "BE", "BOB", "BOD", "BOO", "BOX", "COLD",
    "DORY", "ELM", "ERE", "EX", "FA", "FOB", "FOLK", "HEW", "ILL", 
   "LAB", "LOB", "ME", "MILT", "MOLT", "ORB", "PEE", "PELT", "PERK", 
   "PLY", "PRY"}, 
 13 -> {"AH", "AHA", "ANT", "BALK", "BAR", "CRAG", "CREEL", "ENVY", 
   "ER", "FLAP", "FUR", "GAG", "GEL", "GNAT", "IRK", "NAG", "NU", 
   "NUN", "ONE", "ONYX", "PENT", "PERRY", "RAIL", "RE", "SHE", "SYNC",
    "TANG", "TNT", "TRY", "VEX"}, 
 7 -> {"AH", "AHA", "ALL", "APTLY", "DOLL", "DOPA", "FLAP", "FLU", 
   "GLIB", "HA", "HE", "HO", "IF", "ILK", "ILL", "JOLLY", "LO", "NUB",
    "OBI", "OH", "OLD", "OPT", "PA", "PILE", "SH", "SHALE", "SHE", 
   "SPA", "SPUR", "THY", "VIP", "WHO", "WHY", "WOLD", "ZOO"}, 
 19 -> {"AH", "AT", "AX", "BED", "BEE", "BY", "CHEER", "EH", "GNU", 
   "HA", "HEW", "HIM", "HUB", "IBEX", "IT", "LA", "LATEX", "LAX", 
   "LINK", "LIT", "MAR", "OBI", "PAH", "PAR", "PHEW", "SHH", "TA", 
   "TAT", "TEE", "TIMER", "WHEE", "WHIT", "YEN", "YETI", "ZEBU"}, 
 8 -> {"AIL", "AWE", "AWL", "BIAS", "BIB", "BIZ", "CAM", "COP", "EM", 
   "EMIT", "EWE", "I", "IF", "ILL", "JIB", "JIG", "MOIL", "MOO", 
   "MOW", "MU", "NIB", "NIL", "OIL", "OW", "OWL", "PI", "PIE", "PIG", 
   "PIX", "RIG", "SPIV", "TI", "TIE", "TWIN", "TWO", "UM", "WE", 
   "WET", "WIN", "XI", "ZIP"}, 
 18 -> {"A", "ADD", "AX", "BAT", "BAY", "EGAD", "EGG", "EGO", "EM", 
   "FAD", "FAT", "GAD", "GO", "GOD", "HA", "HAP", "HAW", "HAY", "JAY",
    "KHAN", "LA", "LAW", "LOAF", "LOG", "ME", "OAF", "OW", "OWL", 
   "PA", "RAH", "SAD", "SOD", "SOW", "TAR", "TASK", "TAT", "UGH", 
   "USE", "WE", "WEAL", "WOW"}, 
 10 -> {"BED", "BONY", "BOON", "BOP", "COD", "COG", "COO", "COWS", 
   "CRED", "DEW", "DRY", "DYED", "GO", "GOD", "GOO", "GOON", "GROG", 
   "KC", "KW", "LEI", "LIDO", "LO", "LOO", "LOOP", "MEN", "MONO", 
   "NOON", "OH", "OW", "OWE", "OX", "POI", "POX", "RED", "ROB", "ROW",
    "SNOW", "UM", "WE", "WEN", "WOOD", "ZED", "ZOO"}, 
 16 -> {"AM", "AS", "BE", "BEE", "BEEF", "BUY", "BYTE", "CEDE", "CUD",
    "DEED", "EM", "EMU", "EN", "EX", "FEN", "FEY", "HEM", "HER", 
   "HUT", "IDEM", "KC", "MEET", "MU", "MUD", "PEE", "PUT", "REDO", 
   "REED", "REF", "RUT", "SEE", "SEMI", "SET", "SEW", "SHUT", "THO", 
   "TOUT", "TUM", "WE", "WEE", "WEED", "WET", "WHEW"}, 
 4 -> {"AIR", "EAR", "EEL", "EH", "EPOCH", "ER", "EX", "FEE", "FER", 
   "FIX", "GET", "HEAR", "HERO", "IQ", "JERK", "KEPI", "KIP", "LEA", 
   "LET", "LIT", "MU", "NIX", "OLD", "PEA", "PEAR", "PEG", "PET", 
   "PIE", "PIER", "PIX", "PSST", "REF", "SAP", "SHH", "STEP", "STIR", 
   "TEA", "TEAR", "TEMP", "TIE", "TIGER", "TYRO", "VET", "VEX", "WEB",
    "WET"}, 
 22 -> {"AAH", "AD", "ALKYD", "AN", "AT", "AWN", "BAA", "BAN", "BET", 
   "CAP", "DANK", "DAWN", "EM", "FANG", "GALE", "GEL", "HAP", "HAW", 
   "HEP", "IQ", "JET", "KHZ", "LAC", "LAP", "LAW", "LAWN", "LEA", 
   "LEAN", "LET", "LOOP", "NAB", "ODD", "OPAL", "OPEN", "OWL", "PAIL",
    "PAW", "PAWN", "PEA", "PECAN", "PUNK", "RAP", "RAT", "SAP", "SAX",
    "WEN"}, 
 12 -> {"AT", "BAP", "BEEF", "BUS", "DAMP", "DUB", "DUN", "FA", "FAB",
    "FAD", "FAY", "FAZE", "HUB", "HUM", "IMP", "IQ", "ME", "MEW", 
   "MIX", "MUD", "MY", "NAB", "NAN", "NAP", "NUN", "OAF", "OAK", "PA",
    "PAPA", "PAS", "PUB", "PUP", "PUS", "RAJ", "RUN", "SANE", "SAP", 
   "SKY", "SURF", "TA", "TAB", "TAN", "TAP", "TUB", "UP", "VAN", 
   "YAP", "YE", "ZAP"}, 
 14 -> {"AIR", "AM", "AS", "ASK", "AWL", "BIB", "BOB", "BOD", "BOP", 
   "COT", "COY", "DID", "DIG", "DIP", "DO", "DODO", "DOG", "FIB", 
   "FOX", "GIFT", "GOBS", "GOD", "GYM", "HIP", "HO", "HOB", "HOD", 
   "HOP", "ID", "JOB", "MOD", "MS", "NOD", "OH", "PIG", "POD", "PSST",
    "RIB", "RIP", "ROAD", "TO", "TOM", "TONS", "TOP", "TOR", "VIA", 
   "VIP", "WAD", "WE"}, 
 6 -> {"AS", "BOG", "CORE", "CORK", "COT", "COTE", "COZY", "CURL", 
   "CUT", "DO", "HAJ", "HALL", "HAM", "HAS", "HAT", "HAY", "HE", 
   "HOT", "HUE", "HUG", "HUH", "HUM", "HUSH", "INGOT", "JAM", "JOT", 
   "JUT", "LAM", "LATTE", "LAX", "LAYOUT", "LOT", "LOX", "MALL", 
   "MARL", "MAT", "MATTE", "MOM", "MOT", "MU", "NAN", "NEST", "NO", 
   "NOB", "NU", "OUT", "OW", "PARE", "POSSE", "PUNT", "RAM", "ROUT", 
   "RUIN", "RUM", "SATIN", "SO", "SOD", "TA", "TAT", "TOR", "TUT", 
   "TUX", "VAT", "WAG", "WAGE", "YAK", "YETI"}, 
 20 -> {"BIN", "BOA", "BOB", "BOG", "BOMB", "BOY", "BUD", "BUFF", 
   "BUG", "BUM", "BUN", "BUS", "BY", "CHAIN", "DIN", "DON", "DUG", 
   "FIN", "FIR", "FUG", "FUNNY", "FUR", "FUSION", "GIG", "GIN", "GO", 
   "GUFF", "GULF", "GUN", "GUNNY", "HI", "HIV", "HO", "HUH", "HYMN", 
   "ION", "IQ", "JIMMY", "JOHN", "JULY", "LION", "LOCH", "LOG", "LUG",
    "MI", "MIX", "MUNCH", "NIL", "NON", "NOR", "NU", "NUN", "PUN", 
   "QUA", "QUAY", "SUE", "SYNC", "UM", "VIA", "WILE", "WILY", "WIN", 
   "WINY", "WITS", "WOLF", "WON", "XI"}}

Nice, just a corretion in the code (A -> alpha)

Thread[Rule[alpha, RotateLeft[alpha, #]]]]} & /@ Range[26];

Update: Code is already corrected in original post.

You're welcome, I just notice the "A" out of place and tested the code. :-)

As Caesar encrypted with a shift of 3, shifting by 23 will decrypt CaesarCipher["yhqlylglylfl", 23]

Producing a famous quote from Caesars Gallic Wars.

It helped to notice that it was three words of four characters that start with the same character (and a lot of "L"). It cannot be "alea iacta est" or "aut Caesar aut nihil" for that reason. :-)

Though I did a brute force to confirm it.

I came, saw and won.

please make test bigger on Zoom lecture now