Finding length of a key for a given vigenere cipher using Index of Coincidence I'm developing an algorithm that takes in a vigenere cipher and produces the key length automatically. However, I'm having trouble understanding how to detect the key length when there are multiple large index of coincidences.

For example, given this cipher:

vptnvffuntshtarptymjwzirappljmhhqvsubwlzzygvtyitarptyiougxiuydtgzhhvvmum
shwkzgstfmekvmpkswdgbilvjljmglmjfqwioiivknulvvfemioiemojtywdsajtwmtcgluy
sdsumfbieugmvalvxkjduetukatymvkqzhvqvgvptytjwwldyeevquhlulwpkt


My algorithm produces the following indexes of coincidences for each possible key length:

KL IoC
 1 0.04494435235614492    --&gt;  4%
 2 0.0457833618884447     --&gt;  5%
 3 0.04358853643122834    --&gt;  4%
 4 0.04749622926093514    --&gt;  5%
 5 0.039361207897793266   --&gt;  4%
 6 0.04714370596723538    --&gt;  5%
 7 0.09099225897255454    --&gt;  9%
 8 0.04618589743589745    --&gt;  5%
 9 0.04078047556308426    --&gt;  4%
10 0.03611528822055138    --&gt;  7%
11 0.04916033399005535    --&gt;  5%
12 0.05126633986928104    --&gt;  5%
13 0.04468864468864469    --&gt;  4%
14 0.09884877027734174    --&gt;  10%
15 0.033455433455433455   --&gt;  3%
16 0.03962703962703963    --&gt;  4%
17 0.04305498423145482    --&gt;  4%
18 0.04747474747474748    --&gt;  5%
19 0.030303030303030304   --&gt;  3%
20 0.03222222222222222    --&gt;  3%
21 0.082010582010582      --&gt;  8%
22 0.0436868686868687     --&gt;  4%
23 0.03260869565217391    --&gt;  3%
24 0.05158730158730159    --&gt;  5%
25 0.03666666666666666    --&gt;  4%
26 0.04441391941391941    --&gt;  4%
27 0.03791887125220458    --&gt;  4%
28 0.1058673469387755     --&gt;  11%


The correct key length for this cipher is indeed "7", but why is it not 14, 21, or 28? Their IoC is higher after all? What can I do within my algorithm to make it produce 7 as the key length rather than 14, 21, or 28 (or vice versa)?
The index of coincidence is significantly higher for


The correct keylength
All its multiples


Even if that is not the correct key, you will have a behavior like that. Assuming you have a high index at length $7$, then by the nature of the algorithm you will have a high index at $14, 21, 28, \dots$, regardless if that is the correct key or not.

So the best stragety would be, just to start with the lowest value and if it doesn't work out move to the next outlier (which is most likely your first value doubled). Things like calculatin the GCD of all the outliers, etc. is not wrong but unnecessary, if you can just iterate through and have a really high chance of success on your first (or first few) tries.

One more thing: This kind of analysis is only faulty for short texts (with being impossible to break if the keylength is as long as the message, and the key is chosen uniformly random and only used once), and for longer texts the law of large numbers (in particular, see the variance of the central limit theorem ) will cause all the other values to be really, really close to what you would exepct from a uniform distribution over the alphabet.