24-08-2019, 07:00 PM
Hi there, Voynichers. First, let me introduce myself: I'm a guy from the Netherlands with a background in linguistics, a general interest in anything to do with language(s) and writing systems, and a tendency to construct the latter myself. I've been a lurker here for some time, a follower of Nick Pelling's and René Zandbergen's sites for quite a bit longer, and generally intrigued by the VM for much of my conscious existence, although I've never done anything serious with it and I don't know what the heck a "Neal key" is even after having read You are not allowed to view links. Register or Login to view.. ;)
Regarding the VM text, I suppose I'm largely on the side of most members here: I don't think any of the "solutions" to the text offered thus far have been of much use whatsoever (this is the polite version of my true feelings as a linguist), but I wouldn't dare claiming I have a better clue myself. Safe to say that my cryptology skills don't go nearly as far as my fascination with it.
That said, I've recently been thinking about an idea, and was wondering if you would happen to know if this has ever been considered before (cue Yes it has, you utter noob, leave this to the big kids) or even sounds remotely plausible. I came up with it because some of my conscripts/langs/thingies work on the same basic principle, which you could call a "relative code": i.e., the meaning of a linguistic unit (character, word, whatever) is not determined by its "absolute" value, but by its difference in value with adjacent units.
A simple example to illustrate the principle. Say you want to encipher the word BOOK. To do this, you note the numeric positions of each letter in the alphabet (2-15-15-11), which you then use as steps to be taken forward through the alphabet for each subsequent letter (starting back at the beginning when you get past 26) to get your ciphertext. You need to choose a starting point beforehand; say the letter A. Then, to encipher the first letter of your plaintext (B), you add the value of that letter (2) to the value of your chosen starting letter (A = 1), which in our example gives you 3, which corresponds to C. The C is then taken as the starting point for the next letter, and so on for each step:
A + B = 1 + 2 = 3 = C
C + O = 3 + 15 = 18 = R
R + O = 18 + 15 = 33(mod26) = 7 = G
G + K = 7 + 11 = 18 = R
The plaintext BOOK is thus enciphered as CRGR. Note how the same plaintext character can end up as different ciphertext characters (the first O has become an R; the second one a G), and vice versa (the first O and the K are both enciphered as R).
Should we want to decipher the message CRGR, we must calculate the differences (in terms of numeric value) between each subsequent pair of letters; hence the term "relative code." Counting backwards from the end of the ciphertext, the "difference" between R and G is K, the difference between G and R is O; the difference between R and C is O again; and the difference between C and the letter you chose as your starting point (A) is B. There we are, back at BOOK.
Now this is of course a very simple example, and I'm not expecting the VM text to do anything as straightforward as this or we'd have found out long ago--at least on a letter-by-letter basis. However, could it be the case that something akin to this principle is going on between certain subsequent words (or even larger units)? The fact that so many passages consist of similar-but-not-quite-similar words (pdsheody shdol shey otchdy dshedy soeeedy dchefoey sair shedy sodair) makes me wonder if it would make sense to look at the differences between adjacent words rather than at their surface forms. I.e., not look at otchdy dshedy per se, but at the operations necessary to get from otchdy to dshedy--whatever those operations may be.
Whew. This took more writing than I expected; sorry for that and thanks for bearing with me (assuming you did). Does this make any sense whatsoever, or have I fallen into the most ridiculous trap imaginable? Has this principle been considered before? I'm genuinely curious what you gals 'n' guys think of my idea, and I promise I won't get offended if you burn it to the ground where it belongs. ;)
Thanks a bunch for your consideration, and keep up the great work on the narrow road of sanity!
Regarding the VM text, I suppose I'm largely on the side of most members here: I don't think any of the "solutions" to the text offered thus far have been of much use whatsoever (this is the polite version of my true feelings as a linguist), but I wouldn't dare claiming I have a better clue myself. Safe to say that my cryptology skills don't go nearly as far as my fascination with it.
That said, I've recently been thinking about an idea, and was wondering if you would happen to know if this has ever been considered before (cue Yes it has, you utter noob, leave this to the big kids) or even sounds remotely plausible. I came up with it because some of my conscripts/langs/thingies work on the same basic principle, which you could call a "relative code": i.e., the meaning of a linguistic unit (character, word, whatever) is not determined by its "absolute" value, but by its difference in value with adjacent units.
A simple example to illustrate the principle. Say you want to encipher the word BOOK. To do this, you note the numeric positions of each letter in the alphabet (2-15-15-11), which you then use as steps to be taken forward through the alphabet for each subsequent letter (starting back at the beginning when you get past 26) to get your ciphertext. You need to choose a starting point beforehand; say the letter A. Then, to encipher the first letter of your plaintext (B), you add the value of that letter (2) to the value of your chosen starting letter (A = 1), which in our example gives you 3, which corresponds to C. The C is then taken as the starting point for the next letter, and so on for each step:
A + B = 1 + 2 = 3 = C
C + O = 3 + 15 = 18 = R
R + O = 18 + 15 = 33(mod26) = 7 = G
G + K = 7 + 11 = 18 = R
The plaintext BOOK is thus enciphered as CRGR. Note how the same plaintext character can end up as different ciphertext characters (the first O has become an R; the second one a G), and vice versa (the first O and the K are both enciphered as R).
Should we want to decipher the message CRGR, we must calculate the differences (in terms of numeric value) between each subsequent pair of letters; hence the term "relative code." Counting backwards from the end of the ciphertext, the "difference" between R and G is K, the difference between G and R is O; the difference between R and C is O again; and the difference between C and the letter you chose as your starting point (A) is B. There we are, back at BOOK.
Now this is of course a very simple example, and I'm not expecting the VM text to do anything as straightforward as this or we'd have found out long ago--at least on a letter-by-letter basis. However, could it be the case that something akin to this principle is going on between certain subsequent words (or even larger units)? The fact that so many passages consist of similar-but-not-quite-similar words (pdsheody shdol shey otchdy dshedy soeeedy dchefoey sair shedy sodair) makes me wonder if it would make sense to look at the differences between adjacent words rather than at their surface forms. I.e., not look at otchdy dshedy per se, but at the operations necessary to get from otchdy to dshedy--whatever those operations may be.
Whew. This took more writing than I expected; sorry for that and thanks for bearing with me (assuming you did). Does this make any sense whatsoever, or have I fallen into the most ridiculous trap imaginable? Has this principle been considered before? I'm genuinely curious what you gals 'n' guys think of my idea, and I promise I won't get offended if you burn it to the ground where it belongs. ;)
Thanks a bunch for your consideration, and keep up the great work on the narrow road of sanity!