The bitcoin elliptical curve Secp256k1 has an order which is a prime number . What is the advantage of having a prime number order (if any ) and I assume no subgroups ?

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.

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).

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

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

Sorry , error , i have updated , the problem remains the same

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.

Update on the course quizzes: We are seeing many people who have passed Quiz 1 and a few who have already passed all the quizzes. Keep up the impressive work! We are investigating a couple problem reports from emails received at wolfram-u@wolfram.com. Thank you for sending detailed problem reports when you encounter them.

To clarify the video logging, this is a feature of the course, and videos watched outside of the course (in the Study Group) are not tracked with your course progress. We do have attendance and recording views logged for the Study Group, and this, along with quiz results, allows us to issue certificates of program completion for the Study Group. The Introduction to Cryptography Study Group certificate of completion is considered equivalent to the course completion certificate, and we're pleased to offer both options for earning a certificate for this material.

Great find, the elliptic curves notebook by Jouko Teeriaho, Doug!

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

Hi, Michael.

Ah, I see I misspelled the year. I have the first edition from 1995. Thanks for the pointer: I'll see how I can correct that in my notebook.

I like the book even if it's quite old (over 25 years), especially the first chapters which describes some of the classical ciphers together with cryptanalyses/attacks on them together with small instructive examples. And now I'm preparing for tomorrow's lesson on RSA. :-)

There are later versions of the book. The latest is - according to Amazon - a fourth edition from 2018: https://www.amazon.com/Cryptography-Theory-Practice-Textbooks-Mathematics/dp/1138197017/ref=sr_1_1?keywords=cryptography+stinson&qid=1644788501&sprefix=stinson+crypt%2Caps%2C183&sr=8-1

Good to know! Thank you, Doug.

(Note: The book by Stinson is from 1995, not 1999 as is stated in the first paragraph.)

(Notebook attached)

Attachments:

Elliptic Curves.nb

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.

ok, so really to use zero to 25 and then use the mod 25 is the best policy...I should have thought to try that. Thanks Hermes, I will recalculate and we can continue. Great conversation here!

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.

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?

Should hash values calculated with the same algorithms but on different platforms agree?

Yes they should. If you find they don't, as pointed out by Dariia and Doug, check whether it's because their output representation is just given in a different way (for numbers -> different bases, etc.) Otherwise it may be due because the data being hashed might have looked the same but is actually different in some way: e.g. for strings: they were provided in different encodings (for example, utf8 vs. utf16 vs. something else). Within WL, check whether the data you want to encode is not "embedded" into an overall WL "object" that would thus change what's going to be actually encrypted.

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

Specify "HexString" as 3rd argument to Hash, by default it produces an integer.

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

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?

I have been looking at how to create a quality metric for various ciphers and came up with a couple of tests. I'm sure there is some standard "cookbook" of tests that get applied but haven't seen such a thing yet. Have a look at my take on this. It considers frequency and statistics to compare the spiky image from lesson 13.

Attachments:

EncryptionQualit...nb

I tried to set up a UTF-8/UTF-16 conversion code in WL, see attached notebook (for UTF-16 it is also important to know what the underlying endianness of the byte stream is). Hope that it helps! Suggestions for improvements are welcome :) maybe at some point this could be turned into an entry into the function repository? (I haven't seen any existing UTF16-related function there).

Using these functions, the UTF16-LE example of Mr. Beveridge would look as follows:

In[1]:= Hash[UnicodeToUTF16LE[ToCharacterCode["password"], "ByteArray"], "MD4", "HexString"]
Out[1]= 8846f7eaee8fb117ad06bdd830b7586c

This agrees with the Python result.

Attachments:

UTF8-UTF16-Conversion.nb

You can always implement others and contribute to the Function Repository too!

That's neat! Thank you for taking on the "assignment" responsibly! You could also try some more complex tests like https://resources.wolframcloud.com/FunctionRepository/resources/ChiSquareRandomnessTest/ and others without having to implement them

Wolfram does not support UTF16 encoding unfortunately

Hi

Can you use UTF-16 encoding with the Hash function in Mathematica?

In Python :-

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/ ).

Here is a notebook exploring if some of WL's simpler hash functions generates hash collisions for some of WL's wordlists.

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...

Three years of Latin in high school helped confirm my decryption and translation. Good fun!

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.

What you see in In[1] is due to the fact that in Wolfram an empty byte array is actually a list:

In[1]:= ByteArray[{}]

Out[1]= {}

In[2]:= ByteArray[{}] == List[]

Out[2]= True

So since in WL you can encrypt any expression not just bytes or strings this gets treated as expression List[] and serialized as a generic expression. If you really want to encrypt an empty thing try empty string "". What you see in the inputs 3, 4, and 5 is related to a standard convention on padding, which will be covered in lesson "Block and stream ciphers next week" so I hope you wouldn't mind waiting for that.

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.

I came, saw and won.

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

Another take on this, though it might be overkill for this problem. But let's say that - for some reason - we don't want to test all the possible Caesar shifts, for example if they are too costly

Then we can use the observation that the letter "l" is more frequent than the other letters:

text = "yhql ylgl ylfl";
CharacterCounts[text]

This shows that "l" is most frequent character.

<|"l" -> 5, "y" -> 3, " " -> 2, "f" -> 1, "g" -> 1, "q" -> 1,   "h" -> 1|>

What will be the first substitute to test, i.e. what is the commonest character in Latin?

Unfortunately, there is no letter frequency for Latin in WL:

LanguageData["Latin", "LetterFrequency"]

outputs Missing["NotAvailable"]

So we have to roll our own:

latinWords = WordList["KnownWords", Language -> "Latin"];
CharacterCounts[StringJoin[latinWords]]

which outputs the following, showing that the character "i" is the most common character in Latin.

<|"i" -> 6307, "e" -> 6008, "s" -> 5359, "a" -> 5324, "u" -> 5276, 
 "o" -> 5189, "r" -> 5013, "t" -> 4035, "n" -> 3395, "c" -> 3240, 
 "l" -> 2763, "m" -> 2490, "p" -> 2220, "d" -> 1609, "b" -> 1004, 
 "g" -> 946, "f" -> 896, "v" -> 869, "h" -> 469, "x" -> 409, 
 "q" -> 363, "y" -> 97, "æ" -> 94, "j" -> 51, "C" -> 38, "A" -> 34, 
 "H" -> 19, "M" -> 16, "z" -> 13, "I" -> 12, "T" -> 11, "P" -> 11, 
 "B" -> 10, "S" -> 9, "R" -> 8, "L" -> 8, "V" -> 6, "G" -> 6, 
 "*" -> 5, "O" -> 4, "F" -> 4, "N" -> 3, "E" -> 3, "D" -> 3, "k" -> 3,
  "Æ" -> 3, "Z" -> 2, "\[Hyphen]" -> 2, "U" -> 1, "-" -> 1, "Q" -> 1|>

Let's now use this knowledge to first test the shift that replaces an "i" with "l":

alpha = Alphabet[];
shift = LetterNumber["i"] - LetterNumber["l"];
keytable = Thread[Rule[alpha, RotateLeft[alpha, shift]]];
StringReplace["yhql ylgl ylfl", keytable]

Which happens to be the correct one:

veni vidi vici

Note: The shift found is -3 which is the same as shift 23 (26 + -3 = 23).

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.

Table[ResourceFunction["CaesarCipher"]["yhql ylgl ylfl", i], {i, 1, 26}] 

shows the decrypted message in item 23.

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.

please make test bigger on Zoom lecture now

This will be covered more ahead in Hybrid Cryptography lesson.

For anyone interested in seeing actual historical equipment, the NSA runs the National Cryptological Museum in Maryland. It has an amazing collection from ancient times through Cold War to modern times including Enigmas and they have the only surviving Bombe (the machine designed at Bletchley Park to decrypt Enigma -- the British destroyed all of theirs and had to rebuild one for their recently opened Bletchley Park museum).

Interesting historical perspective of cryptography from day 1 - looking forward to the next sessions!

Over 200 attendees joined the first session of this study group today. Thanks @Dariia Porechna for your presentation. Thanks to the attendees for remaining engaged throughout the session. Looking forward to the rest of the series.