Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #74314 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-10-30 08:23 -0700 |
| Last post | 2015-11-04 09:50 +0100 |
| Articles | 20 on this page of 68 — 15 participants |
Back to article view | Back to comp.lang.c
Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 08:23 -0700
Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-10-30 15:39 +0000
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 09:33 -0700
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:33 +0000
Re: Program to cipher a text, new thread, fresh one Mark Storkamp <mstorkamp@yahoo.com> - 2015-10-30 11:17 -0500
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 09:32 -0700
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:38 +0000
Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-10-30 10:55 -0600
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 10:07 +0000
Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 10:42 +0000
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 11:35 +0000
Re: Program to cipher a text, new thread, fresh one James Kuyper <jameskuyper@verizon.net> - 2015-11-01 08:33 -0500
Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 16:09 +0000
Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-11-02 12:43 +0000
Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-02 13:25 +0000
Re: Program to cipher a text, new thread, fresh one Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 06:13 -0800
Re: Program to cipher a text, new thread, fresh one Keith Thompson <kst-u@mib.org> - 2015-11-01 12:26 -0800
Re: Program to cipher a text, new thread, fresh one supercat@casperkitty.com - 2015-11-01 07:59 -0800
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-02 13:48 +0000
Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-11-02 14:06 +0000
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-02 14:51 +0000
Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-11-02 15:48 +0000
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-02 16:00 +0000
Re: Program to cipher a text, new thread, fresh one asetofsymbols@gmail.com - 2015-11-03 01:40 -0800
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 11:16 +0000
Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-11-03 05:21 -0600
Re: Program to cipher a text, new thread, fresh one asetofsymbols@gmail.com - 2015-11-03 03:41 -0800
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 11:53 +0000
Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-11-03 05:57 -0600
Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 12:48 +0000
Re: Program to cipher a text, new thread, fresh one Rosario19 <Ros@invalid.invalid> - 2015-11-04 09:09 +0100
Re: Program to cipher a text, new thread, fresh one Rosario19 <Ros@invalid.invalid> - 2015-11-04 09:37 +0100
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-11-04 07:09 -0800
Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-11-03 05:53 -0600
Re: Program to cipher a text, new thread, fresh one asetofsymbols@gmail.com - 2015-11-03 04:29 -0800
Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-11-03 06:42 -0600
Re: Program to cipher a text, new thread, fresh one Geoff <geoff@invalid.invalid> - 2015-11-01 08:07 -0800
Re: Program to cipher a text, new thread, fresh one Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:26 -0800
Re: Program to cipher a text, new thread, fresh one Rosario19 <Ros@invalid.invalid> - 2015-11-06 07:53 +0100
Re: Program to cipher a text, new thread, fresh one Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-07 10:01 -0800
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 10:50 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 10:53 -0700
Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-30 11:52 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 12:12 -0700
Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-30 21:05 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 23:58 -0700
Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-31 03:09 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 03:47 -0700
Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-31 11:42 -0700
Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-30 12:04 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 12:10 -0700
Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-10-30 13:17 -0600
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 00:04 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 00:25 -0700
Re: Program to cipher a text, new thread, fresh one Keith Thompson <kst-u@mib.org> - 2015-10-30 12:34 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 21:49 -0700
Re: Program to cipher a text, new thread, fresh one Keith Thompson <kst-u@mib.org> - 2015-10-31 13:18 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 00:29 -0700
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 01:12 -0700
Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 12:24 +0000
Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 06:11 -0700
Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-10-31 15:58 +0000
Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 17:37 +0000
Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-10-31 18:14 +0000
Re: Program to cipher a text, new thread, fresh one Keith Thompson <kst-u@mib.org> - 2015-10-31 13:29 -0700
Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:35 +0000
Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:32 +0000
Re: Program to cipher a text, new thread, fresh one Rosario19 <Ros@invalid.invalid> - 2015-11-04 09:50 +0100
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-02 14:51 +0000 |
| Message-ID | <n17t5b$hjv$1@dont-email.me> |
| In reply to | #74643 |
On 02/11/15 14:06, Bartc wrote: > On 02/11/2015 13:48, Richard Heathfield wrote: >> On 01/11/15 15:59, supercat@casperkitty.com wrote: > >>> From what I understand, common cryptographic practice was to strip >>> out all >>> punctuation and word spaces, see if the message made sense, if it didn't >>> either rewrite it and/or add some obvious "noise characters" like Q or X >>> to imply word breaks, then encipher the message and add word breaks at >>> regular intervals. Preserving original word spaces and punctuation >>> would >>> give excessively strong clues as to the message content, which could not >>> only assist in deciphering it, but could even allow the enemy to glean >>> information *without* deciphering it. >> >> >> Whether most users would have been that cautious, knowing as they did >> that the cipher was unbreakable, is probably an open question. > > It wouldn't have taken long to discover that, if the encryption > preserves spaces, it is sometimes possible to guess what the words might > be from the 'shape' of the sentences. Oh, it's easy enough to do that if you don't mind getting it wrong... > > Here's a couple of examples, with clues to help out: > > XXXXX XXXXX (70s pop star; from a Hangman game) Chuck Berry Chuck Brown David Bowie David Essex Eddie Money Carly Simon Ringo Starr Frank Zappa ...to name but a few. > > X XXXXXXX XX XXXXX (Book and film; from a crossword) I found 68 films that would fit. I have no idea how many of them are also books, but I'd guess quite a few. > You can regard the Xs as a tough form of cipher where any letter maps to > 'X'. May I introduce Bob? He isn't very happy with you. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-02 15:48 +0000 |
| Message-ID | <n180gf$v38$1@dont-email.me> |
| In reply to | #74648 |
On 02/11/2015 14:51, Richard Heathfield wrote: > On 02/11/15 14:06, Bartc wrote: >> On 02/11/2015 13:48, Richard Heathfield wrote: >>> Whether most users would have been that cautious, knowing as they did >>> that the cipher was unbreakable, is probably an open question. >> >> It wouldn't have taken long to discover that, if the encryption >> preserves spaces, it is sometimes possible to guess what the words might >> be from the 'shape' of the sentences. > > Oh, it's easy enough to do that if you don't mind getting it wrong... > >> >> Here's a couple of examples, with clues to help out: >> >> XXXXX XXXXX (70s pop star; from a Hangman game) > > Chuck Berry > Chuck Brown > David Bowie > David Essex > Eddie Money > Carly Simon > Ringo Starr > Frank Zappa > > ...to name but a few. You seem to be more clued up than I was! (Actually I didn't have any clue apart from knowing my opponent; the answer was David Essex.) >> X XXXXXXX XX XXXXX (Book and film; from a crossword) > > I found 68 films that would fit. I have no idea how many of them are > also books, but I'd guess quite a few. Well, I find multi-word cryptic crossword answers easier than single-word ones. (1,7,2,5) in this example was enough to give me A Passage To India. You can at least deduce that the lone X might be A or I, while XX is going to be something like OF, IN, TO, AT, BY etc. That's much harder without spaces XXXXXXXXXXXXXXX, or with spaces turned into Qs in the plain text: XXXXXXXXXXXXXXXXXX. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-02 16:00 +0000 |
| Message-ID | <n18171$29k$1@dont-email.me> |
| In reply to | #74651 |
On 02/11/15 15:48, Bartc wrote: <snip> > You can at least deduce that the lone X might be A or I, while XX is > going to be something like OF, IN, TO, AT, BY etc. > > That's much harder without spaces XXXXXXXXXXXXXXX, or with spaces turned > into Qs in the plain text: XXXXXXXXXXXXXXXXXX. No, it's no harder at all, not if it's a Vigenere cipher. The spaces are of no consequence. The length of the key generally falls quite quickly to a Kasiski inspection. Arrange the ciphertext (omitting anything that wasn't encrypted) in rows klen characters wide, and perform a frequency analysis on the columns thus formed. A quick comparison with a corpus analysis will give you the key letter for each column in as little time as it takes you to work out how far out of phase the column's frequencies are with the corpus frequency. That part (the comparison) will normally take you, oh, about a second, assuming you're doing it by eye rather than by computer. For an unbreakable cipher, Vigenere is terribly, terribly fragile, and Eve really doesn't need punctuation and spacing hints, and their absence doesn't slow her down even a little bit. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-11-03 01:40 -0800 |
| Message-ID | <164603bf-24f0-45ab-a264-776ae541bae2@googlegroups.com> |
| In reply to | #74653 |
If I understood good
Vigene use one permutation over
letters
permutation:{letters}->{letters}
Than it is easy...
Copy the linear random generator in
K&R change some number in it
make it portable call it randKR()
Make one other randKR1() function
as above
Use the key to initialize the seeds
that randKR() and randKR1()
function use
Use randKR() for build one permutation p:0..255->0..255
Use one algo can combine
steams randKR() and randKR1()
for obtain stream s3() as it return
one 'random' char at time
Get the first char of stream to crypt
xor s3() apply p() to that char
write that char in string out
For the reverse:
Get the same key above
with that initialize
randKR() and randKR()
calculate p
calculate p^-1
get the stream s3()
Get first char of input
apply xor s3()
apply p^-1
write in the string out
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-03 11:16 +0000 |
| Message-ID | <n1a4tj$ftb$1@dont-email.me> |
| In reply to | #74737 |
On 03/11/15 09:40, asetofsymbols@gmail.com wrote:
> If I understood good
> Vigene use one permutation over
> letters
> permutation:{letters}->{letters}
> Than it is easy...
Your method will produce a cipher (at first glance, it looks to me like
a fairly ordinary stream cipher), but not the classic Vigenere cipher.
Deduction: you did not understand the Vigenere cipher.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-11-03 05:21 -0600 |
| Message-ID | <d9rjlmFkhkbU1@mid.individual.net> |
| In reply to | #74737 |
<asetofsymbols@gmail.com> wrote:
> If I understood good
> Vigene use one permutation over
> letters
> permutation:{letters}->{letters}
> Than it is easy...
>
> Copy the linear random generator in
> K&R change some number in it
> make it portable call it randKR()
I don't know what Vigene is. If it is a re-spelling of Vigenere, you do not
understand. Random numbers are not involved in the Vigenere cipher. Look
at Wikipedia.
<snip>
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-11-03 03:41 -0800 |
| Message-ID | <fa553cd6-40cb-4f46-b3df-e04e7639953d@googlegroups.com> |
| In reply to | #74740 |
Osmium wrote: I don't know what Vigene is. If it is a re-spelling of Vigenere, you do not understand. Random numbers are not involved in the Vigenere cipher. Look at Wikipedia. <snip> ----- Yes that one... 'Vigenere' . But one has to use random number for to have the permutation from the text key (or do you enter the permutation as input key?? It is a little difficult) Than I would make a little strong the algo using xor one 'random' stream
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-03 11:53 +0000 |
| Message-ID | <n1a73k$ng2$1@dont-email.me> |
| In reply to | #74742 |
On 03/11/15 11:41, asetofsymbols@gmail.com wrote: > Osmium wrote: > I don't know what Vigene is. If it is a re-spelling of Vigenere, you do not > understand. Random numbers are not involved in the Vigenere cipher. Look > at Wikipedia. > <snip> > ----- > Yes that one... 'Vigenere' . > But one has to use random number > for to have the permutation > from the text key No, there are no permutations in Vigenere. > (or do you enter the permutation > as input key?? It is a little > difficult) The key is decided upon by the sender and recipient. (Actually, the recipient doesn't need to know the key, strictly speaking, but to know it will make his life slightly easier than that of anyone listening in.) > Than I would make a little strong > the algo using xor one > 'random' stream Yes, but then it wouldn't be Vigenere any more. It's like saying "I'm going to lock my door using the classical technique of hanging a 'Please Do Not Break In' sign on the door. Except that that isn't very secure, so I'm going to add a 0.5mm steel bolt to the door as well." Does that improve security? Well, yes, it does, a little bit. But it's no longer the original technique. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-11-03 05:57 -0600 |
| Message-ID | <d9rlq3Fl21aU1@mid.individual.net> |
| In reply to | #74743 |
"Richard Heathfield" wrote: > The key is decided upon by the sender and recipient. (Actually, the > recipient doesn't need to know the key, strictly speaking, but to know it > will make his life slightly easier than that of anyone listening in.) Note that Richard has several modes. That was not an example of his "helpful" mode.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-03 12:48 +0000 |
| Message-ID | <n1aabd$44b$1@dont-email.me> |
| In reply to | #74746 |
On 03/11/15 11:57, Osmium wrote:
> "Richard Heathfield" wrote:
>
>> The key is decided upon by the sender and recipient. (Actually, the
>> recipient doesn't need to know the key, strictly speaking, but to know
>> it will make his life slightly easier than that of anyone listening in.)
>
> Note that Richard has several modes. That was not an example of his
> "helpful" mode.
<grin> You're right. I do, and it wasn't. To make up for it, here's one
of my Peter-and-Jane-do-techie-stuff explanations.
Vigenere is a polyalphabetic substitution cipher that uses a
substitution table along these lines:
*|ABCDEFGHI...
-+---------...
A|ABCDEFGHI...
B|BCDEFGHIJ...
C|CDEFGHIJK...
D|DEFGHIJKL...
E|EFGHIJKLM...
F|FGHIJKLMN...
G|GHIJKLMNO...
H|HIJKLMNOP...
I|IJKLMNOPQ...
and so on, in both directions: a 26x26 square. (In the body of the
table, the alphabet wraps around, like this: ...UVWXYZABCD..., where
necessary.)
The sender (often known as Alice) and the recipient (typically hailed as
Bob) agree upon a key. Say, "FACE", for example.
To encrypt the first letter of the message, Alice finds the row of the
table corresponding to that letter, and the column corresponding to the
first letter of the key. Where that row and column cross, that's the
enciphered letter. So if the message is, say, "CHEF DECIDED FIG BAD",
then Alice looks up row C and column F, and finds that they intersect at
H. So H is the first letter of the ciphertext.
The key letter F is now considered "used", and has to go to the back of
the line: from FACE to ACEF. (In a computer simulation of Vigenere, you
don't have to do that literally - modulo arithmetic will do:
k++; k %= klen;
The second letter of the message, H, is enciphered with the next letter
of the key, which is A. So Alice looks up row H and column A, and finds
the letter H there. So H is the second letter of the ciphertext too. And
let's move that key letter to the back:
Plain-text: CHEF DECIDED FIG BAD
Ciphertext: HH
Key: currently CEFA
Next, we want to encipher the E, so we look up row E column C, and we
find G (just as well - if it had been H again, that would have been
mildly spooky), and move the key letter C to the back:
Plain-text: CHEF DECIDED FIG BAD
Ciphertext: HHG
Key: currently EFAC
Now we encipher F by looking up row F and column E (the key, remember),
which gives us J, and we must remember to move the key letter E to the back:
Plain-text: CHEF DECIDED FIG BAD
Ciphertext: HHGJ
Key: currently FACE
And you will see that our key is back where it started, but that's okay
- we just plough on as if nothing had happened. So D is enciphered by
looking up row D column F and finding I there, and we remember to move
the key letter to the back:
Plain-text: CHEF DECIDED FIG BAD
Ciphertext: HHGJ I
Key: currently ACEF
and, in finest Blue Peter tradition, here's the rest of it, which I
prepared earlier:
Plain-text: CHEF DECIDED FIG BAD
Ciphertext: HHGJ IEEMIEF JNG DEI
Key: currently ACEF
Okay, if Alice is sensible she will decode that to make sure it all
still makes sense. To do that, she starts at the beginning, including
setting the key back to FACE, and she looks down the key column (F)
until she finds the ciphertext letter (H). Then she reads across to the
left, to get the plaintext letter (C). She moves that key letter to the
back as before, and does the same with the next ciphertext letter, and
so on, until she's decoded the whole thing.
I am not as sensible as Alice, so I didn't bother. (Did I get it right
anyway? I don't know. I expect so.)
Alice can now squish out all the spaces if she wants, and send the
ciphertext to Bob, who can decipher it as explained above.
Eve, an eavesdropper, is listening in on the radio, and she copies down
the Morse code beeps and turns them into ciphertext letters.
To read the message, she first has to find out the key length. This she
does by offsetting the message against itself by all plausible key
lengths, and counting how many times a letter appears in the same column
in both rows:
HHGJIEEMIEFJNGDEI
*HHGJIEEMIEFJNGDEI
-1----1---------- = 2
HHGJIEEMIEFJNGDEI
**HHGJIEEMIEFJNGDEI
----------------- = 0 (not unusual for such a short message)
HHGJIEEMIEFJNGDEI
***HHGJIEEMIEFJNGDEI
---------1------- = 1
HHGJIEEMIEFJNGDEI
****HHGJIEEMIEFJNGDEI
--------11------- = 2
and so on, up to the whole length of the message if need be.
For such a short message, the result is a little ambiguous, but for a
message of a reasonable length there is a definite "spike" when we have
the key length or a multiple thereof.
I know that sounds a little wobbly, but in practice it really does work.
Having ascertained the key length, we divide the message up into rows,
one key's worth per row:
HHGJ
IEEM
IEFJ
NGDE
I
The point here is that, in any given *column*, every ciphertext letter
was encrypted using the *same* key letter. At this point, we are able to
use the same simple cracking technique (frequency analysis) as works for
ordinary cryptograms (monoalphabetic substitution ciphers). And in
practice we need only find 'e', because everything else will fall into
place.
So, in very short order, we can read the message even if we don't have
the key.
This has been a long article with not much C, so let's have some C now.
The following program performs a Kasiski examination for you. It tries
every possible key length, and gives you the number of matches for that
key length (the higher the match count, the more likely it is that you
have the right key length). The output is in CSV format for easy import
into a spreadsheet and sorting by matches.
The "get the size of the file" function is a bodge, of course. In real
life, I use stat() - this is a for-comp.lang.c-only edited version.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
size_t get_file_length(const char *filename)
{
size_t count = 0;
FILE *fp = fopen(filename, "rb");
if(fp != NULL)
{
while(getc(fp) != EOF)
{
++count;
}
fclose(fp);
}
return count;
}
void get_key_length(unsigned char *buf,
size_t len,
unsigned char *compare)
{
unsigned long *result = calloc(len, sizeof *result);
if(result != NULL)
{
size_t offset = 0;
while(++offset < len)
{
size_t whichbyte = 0;
while(whichbyte < len)
{
if(compare[offset + whichbyte] ==
buf[whichbyte])
{
++result[offset];
}
++whichbyte;
}
}
printf("Offset,Matches\n");
for(offset = 0; offset < len; offset++)
{
if(result[offset] > 0)
{
printf("%lu,%lu\n",
(unsigned long)offset,
result[offset]);
}
}
free(result);
}
else
{
fprintf(stderr,
"Couldn't allocate storage for results.\n");
}
}
int main(int argc, char **argv)
{
if(argc > 1)
{
size_t len = get_file_length(argv[1]);
unsigned char *file = malloc(len);
unsigned char *comparator = malloc(2 * len);
if(file != NULL && comparator != NULL)
{
FILE *fp = fopen(argv[1], "rb");
if(fp != NULL)
{
size_t bytes = fread(file, 1, len, fp);
if(bytes == len)
{
memcpy(comparator, file, len);
memcpy(comparator + len, file, len);
get_key_length(file, len, comparator);
}
else
{
fprintf(stderr,
"File read error on %s - needed"
" %lu bytes, got %lu bytes.\n",
argv[1],
(unsigned long)len,
(unsigned long)bytes);
}
fclose(fp);
}
else
{
fprintf(stderr,
"Can't open %s for reading.\n",
argv[1]);
}
}
else
{
fprintf(stderr,
"Insufficient memory - need %lu bytes.\n",
(unsigned long)len);
}
free(comparator); /* NB free(NULL) is a
guaranteed NOP */
free(file);
}
else
{
fprintf(stderr,
"Specify a filename for Kasiski to examine.\n");
}
return 0;
}
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-11-04 09:09 +0100 |
| Message-ID | <luej3btiasfau4e51o5veu4jdiscg30nsd@4ax.com> |
| In reply to | #74751 |
On Tue, 3 Nov 2015 12:48:48 +0000, Richard Heathfield
<rjh@cpax.org.uk> wrote:
>
>*|ABCDEFGHI...
>-+---------...
>A|ABCDEFGHI...
>B|BCDEFGHIJ...
>C|CDEFGHIJK...
>D|DEFGHIJKL...
>E|EFGHIJKLM...
>F|FGHIJKLMN...
>G|GHIJKLMNO...
>H|HIJKLMNOP...
>I|IJKLMNOPQ...
>
.....
>The key letter F is now considered "used", and has to go to the back of
>the line: from FACE to ACEF. (In a computer simulation of Vigenere, you
>don't have to do that literally - modulo arithmetic will do:
>k++; k %= klen;
>
>The second letter of the message, H, is enciphered with the next letter
>of the key, which is A. So Alice looks up row H and column A, and finds
>the letter H there. So H is the second letter of the ciphertext too. And
>let's move that key letter to the back:
>
>Plain-text: CHEF DECIDED FIG BAD
>Ciphertext: HH
>Key: currently CEFA
>Plain-text: CHEF DECIDED FIG BAD
>Ciphertext: HHGJ IEEMIEF JNG DEI
>Key: currently ACEF
I think i had understood 'Vigenere' thank you
these files can traslate with 2 cryptosystem
Vigenere and xor-permutations
---------------
;the rand function
section _DATA use32 public class=DATA
global rnd
w dd 3234937339, 1236937253, 2236338257, 4134138257
section _TEXT use32 public class=CODE
;u32 __stdcall rnd(u32* seed)
;0b,4ra,8P_seed
align 4
rnd:
<b
b=^8 ; 0 4 8 12 16val 20indice
r=&*b+20 |D*r#.1
a=*w |mul D*b|++a|*b=a|a>>=4|b+=4|c =a
a=*w+ 4|mul D*b|++a|*b=a| b+=4|c+=a
a=*w+ 8|mul D*b|++a|*b=a| b+=4|c+=a
a=*w+12|mul D*b|++a|*b=a| b+=4|c+=a ; b punta a val
*b=c | b+=4|r =b ; b punta a indice
.1: b=&*r-4
c= *r|a=-1|c>=4#.z|a^=a|al=*b+c
++D*r|D*r<4#.z|D*r=0
.z:
>b
ret 4
;-----------------
;its traslate
section _DATA use32 public class=DATA
global rnd
w dd 3234937339, 1236937253, 2236338257, 4134138257
section _TEXT use32 public class=CODE
;u32 __stdcall rnd(u32* seed)
;0b,4ra,8P_seed
align 4
rnd:
push ebx
mov ebx, dword[esp+ 8] ; 0 4 8 12 16val
20indice
lea edx, [ebx+20]
cmp dword[edx], 0
jne .1
mov eax, [w]
mul dword[ebx]
inc eax
mov [ebx], eax
shr eax, 4
add ebx, 4
mov ecx, eax
mov eax, [w+4]
mul dword[ebx]
inc eax
mov [ebx], eax
add ebx, 4
add ecx, eax
mov eax, [w+8]
mul dword[ebx]
inc eax
mov [ebx], eax
add ebx, 4
add ecx, eax
mov eax, [w+12]
mul dword[ebx]
inc eax
mov [ebx], eax
add ebx, 4
add ecx, eax ; b punta a val
mov [ebx], ecx
add ebx, 4
mov edx, ebx ; b punta a indice
.1: lea ebx, [edx-4]
mov ecx, [edx]
mov eax, -1
cmp ecx, 4
jae .z
xor eax, eax
mov al, [ebx+ecx]
inc dword[edx]
cmp dword[edx], 4
jb .z
mov dword[edx], 0
.z:
pop ebx
ret 4
;---------------------
// the C++ file that is not so far from C
#include <stdio.h>
#include <stdlib.h>
#define u32 unsigned
#define i32 int
#define u8 unsigned char
#define R return
#define P printf
#define F for
#define GG(a,b) if(a)goto b
extern "C" {
u32 __stdcall rnd(u32* sd);
}
// this suppose chars are as the ascii table
class Vigenere{
public:
//constructor
Vigenere(u8* k)
{u32 i, j, r;
u8 b, a;
ndx=len=0;
F(i=0; i<0xFFFFF ; ++i)
if(k[i]==0) break;
if(i>=0xFFFFF)
{l0: P("Errore\n"); exit(1);}
key=(u8*)malloc(i+1); GG(key==0, l0);
F(j=0, r=0; j<i&&(a=k[j])!=0; ++j)
{if('a'<=a && a<='z') a-=32;
if(! ('A'<=a && a<='Z') ) // key has only letters cap
continue;
key[r++]=a;
}
key[r]=0; len=r;
}
u32 Crp(u32 c)
{u32 a=c&0xFF, b, r, v;
b=a; // 32='a'-'A'
if('a'<=b && b<='z') b-=32; // make letter caps
if(! ('A'<=b && b<='Z') )
R a; // not letter
r=key[ndx++]; if(ndx==len) ndx=0;
v=r+(b-'A'); if(v>'Z') v-=26;
if(! ('A'<=v && v<='Z') )
{P("Errore di traduzione\n"); exit(1);}
if(a!=b) v+=32;
R v;
}
u32 deCrp(u32 c)
{u32 a=c&0xFF, b, r, v;
b=a;
if('a'<=b && b<='z') b-=32; // make letter caps
if(! ('A'<=b && b<='Z') )
R a; // not letter
r=key[ndx++]; if(ndx==len) ndx=0;
// r+(x-'A')= y => x=y+'A'-r
v=b+'A'-r; if(v<'A') v+=26;
if(! ('A'<=v && v<='Z') )
{P("Errore di traduzione\n"); exit(1);}
if(a!=b) v+=32;
R v;
}
u8* key;
u32 len;
u32 ndx;
};
class prmCr{
public:
friend i32 inizializza(prmCr* v, u32* a)
{u32 i, j, ii, jj, t;
// inizializzazione del generatore
if(a==0||v==0) R -1;
F(i=0; i<4; ++i) v->seed[i]=a[i];
v->seed[4]=0; v->seed[5]=0;
// permutazione identita'
F(i=0; i<256; ++i) v->p[i]=i;
// permutazione dipendente dall'input
F(i=0; i<256; ++i)
F(j=0; j<256; ++j)
{ii=rnd(v->seed)%256; jj=rnd(v->seed)%256;
t=v->p[ii]; v->p[ii]=v->p[jj]; v->p[jj]=t;
}
F(i=0; i<256; ++i) // permutazione inversa
{t=v->p[i]; if(t>255){P("Errore grave\n"); R -1;}
v->pm[t]=i;}
R 0;
}
prmCr(u32* a){inizializza(this, a);}
prmCr(){u32 i; F(i=0; i<256; ++i) p[i]=pm[i]=i;}
u32 Crp(u32 c){u32 a=c&0xFF; a^=rnd(seed); R (u32) p[a&0xFF];}
u32 deCrp(u32 c){u32 a=c&0xFF,b; b =pm[a]; b^=rnd(seed); R b;}
i32 init(u32 *a){R inizializza(this, a);}
u8 p [256];
u8 pm[256];
u32 seed[6]; //4 seed + 1 variabile return rnd, 1 index return
};
FILE *ifile;
FILE *ofile;
int main(int c, char** a)
{u32 key1[4]={12345, 53433, 35566, 8988}, r, led=0, led1=0; //a the
key 4 u32
i32 chi;
u8 *p, keyVigenere[]="FACE", fileOutName[65], ch;
prmCr m(key1);
Vigenere mm(keyVigenere);
// c=1 nessun argomento;c=2 1 arg;c=3 2 arg;c=4 3 arg
if(c!=4)
{// 0 1 2 3
l0: P("Usage:> thisProg -v[-b] -c[-d] FileIn \n");
P("-v use Vigenere sys; -b use my home made sys\n");
P("-c means crypt; -d means decrypt\n");
P("The output file will be FileIn.d or FileIn.c\n");
R 1;
}
p=a[1];
GG(p[0]!='-', l0);
if(p[1]=='v') led1=1;
else GG(p[1]!='b', l0);
p=a[2];
GG(p[0]!='-', l0);
if(p[1]=='d') led=1;
else GG(p[1]!='c', l0);
F(r=0; r<59 && (ch=a[3][r])!=0; ++r)
fileOutName[r]=ch;
if(r>=60) R 1;
if(led) fileOutName[r++]='d';
else fileOutName[r++]='c';
fileOutName[r]=0;
ifile=fopen(a[3], "rb");
if(ifile==0){P("Impossibile apertura di %s\n", a[3]); R 1;}
ofile=fopen(fileOutName, "wb");
if(ofile==0){fclose(ifile);
P("Impossibile apertura di %s\n", fileOutName);
R 1;
}
F(;(chi=getc(ifile))!=EOF;)
{chi=led1?(led?mm.deCrp(chi):mm.Crp(chi)):
(led? m.deCrp(chi): m.Crp(chi));
putc(chi, ofile);
}
if(fclose(ifile)==EOF||fclose(ofile)==EOF)
{P("Errore lettura o scrittura file\n"); R 1;}
else P("traduzione di %s in %s ok\n", a[3], fileOutName);
R 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-11-04 09:37 +0100 |
| Message-ID | <5rgj3bdceqdu0sjisa14qdu5k5rft488q6@4ax.com> |
| In reply to | #74805 |
On Wed, 04 Nov 2015 09:09:23 +0100, Rosario19 wrote:
>class Vigenere{
>public:
>//constructor
>Vigenere(u8* k)
>{u32 i, j, r;
> u8 b, a;
>
> ndx=len=0;
> F(i=0; i<0xFFFFF ; ++i)
> if(k[i]==0) break;
> if(i>=0xFFFFF)
> {l0: P("Errore\n"); exit(1);}
> key=(u8*)malloc(i+1); GG(key==0, l0);
> F(j=0, r=0; j<i&&(a=k[j])!=0; ++j)
> {if('a'<=a && a<='z') a-=32;
> if(! ('A'<=a && a<='Z') ) // key has only letters cap
> continue;
> key[r++]=a;
> }
> key[r]=0; len=r;
>}
>
>u32 Crp(u32 c)
>{u32 a=c&0xFF, b, r, v;
> b=a; // 32='a'-'A'
> if('a'<=b && b<='z') b-=32; // make letter caps
> if(! ('A'<=b && b<='Z') )
> R a; // not letter
> r=key[ndx++]; if(ndx==len) ndx=0;
> v=r+(b-'A'); if(v>'Z') v-=26;
> if(! ('A'<=v && v<='Z') )
> {P("Errore di traduzione\n"); exit(1);}
> if(a!=b) v+=32;
> R v;
>}
>
>u32 deCrp(u32 c)
>{u32 a=c&0xFF, b, r, v;
> b=a;
> if('a'<=b && b<='z') b-=32; // make letter caps
> if(! ('A'<=b && b<='Z') )
> R a; // not letter
> r=key[ndx++]; if(ndx==len) ndx=0;
> // r+(x-'A')= y => x=y+'A'-r
> v=b+'A'-r; if(v<'A') v+=26;
> if(! ('A'<=v && v<='Z') )
> {P("Errore di traduzione\n"); exit(1);}
> if(a!=b) v+=32;
> R v;
>}
>
>
>u8* key;
>u32 len;
>u32 ndx;
>};
i forget destructor
~Vigenere(){free(key);}
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-11-04 07:09 -0800 |
| Message-ID | <e8b3dc9e-d7e6-4de3-b6a9-20c80281126d@googlegroups.com> |
| In reply to | #74751 |
Greetings! I had to forbear from reading the forum - tried to re-read about basics. I see that I have a lot to catch up :) I am happy to do so today - tomorrow. Interesting discussion.
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-11-03 05:53 -0600 |
| Message-ID | <d9rlihFl0bmU1@mid.individual.net> |
| In reply to | #74742 |
<asetofsymbols@gmail.com> wrote: > Osmium wrote: > I don't know what Vigene is. If it is a re-spelling of Vigenere, you do > not > understand. Random numbers are not involved in the Vigenere cipher. Look > at Wikipedia. > <snip> > ----- > Yes that one... 'Vigenere' . > But one has to use random number > for to have the permutation > from the text key > (or do you enter the permutation > as input key?? It is a little > difficult) > Than I would make a little strong > the algo using xor one > 'random' stream I couldn't improve on the Wiki article. I have the vague feeling that you are trying to improve on something you don't understand. If so, I suggest you understand what is already there. First!
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-11-03 04:29 -0800 |
| Message-ID | <041d4e28-4c23-4838-9665-692535dccdf9@googlegroups.com> |
| In reply to | #74742 |
I wrote: Yes that one... 'Vigenere' . ---- I remember wrong... I search with google 'Vigenere' but it is not clear to me what is his method
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-11-03 06:42 -0600 |
| Message-ID | <d9rocqFln8qU1@mid.individual.net> |
| In reply to | #74748 |
<asetofsymbols@gmail.com> wrote: >I wrote: > Yes that one... 'Vigenere' . > ---- > I remember wrong... > I search with google 'Vigenere' > but it is not clear to me > what is his method Try this link: https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher The essence of it is in the drawing of a two-dimensional array of characters shown on the right hand side of the page.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-11-01 08:07 -0800 |
| Message-ID | <l2ec3btck1cj4ut7e7j19kiq3fi2eith5l@4ax.com> |
| In reply to | #74532 |
On Sun, 1 Nov 2015 10:07:32 +0000, Richard Heathfield <rjh@cpax.org.uk> wrote: >I can easily imagine the Vigenere cipher's original users being >case-blind - that is, not actually making any distinction between upper >and lower case either in the keyword or in the message text. I can >equally imagine them skipping punctuation - that is, duplicating it >without consuming key material. Extant examples of the cipher ignored punctuation and spaces. They did not appear in the ciphertext at all. To do so would have weakened the system.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-02 02:26 -0800 |
| Message-ID | <kfnvb9k7l4m.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #74532 |
Richard Heathfield <rjh@cpax.org.uk> writes:
>> [snip]
>
> I can easily imagine the Vigenere cipher's original users being
> case-blind - that is, not actually making any distinction between
> upper and lower case either in the keyword or in the message text. I
> can equally imagine them skipping punctuation - that is, duplicating
> it without consuming key material.
>
> Even with these apparent complications, it is not a difficult problem,
> and neither is Alla's code particularly complicated - which is not to
> say that it could not be simplified.
>
> The first step I would take towards simplifying the implementation is
> to record the case of an input character, and thereafter do everything
> in lower case, translating back at the end if need be. [snip]
I took a different approach. Here is the resulting program
and sample output.
#ahrplfe <wqrzty.p>
#tvuecfi <piliz.p>
#lbetixw <kngmei.h>
#tvhcujm <nbqim.j>
wqpbin cqgkobyv ubpv kcbwmfl[26][UIPLZ_ETF];
krq
biiy( qqh czuw, uzug *eiiv[] ){
npfi lkbemjl[] = "idgatngsqmynubihilhxlxwige";
thgz WMLMMTW[] = "XQKDPNJVKRYFEFIEUIUTFDBOYF";
ksij *dma = eovk > 1 ? acoy[1] : "gwxslusfxjicgttnjtokpfhbinmadkizcv";
wpb w, d, u, F = mivcgn( vmd );
lnyqrvww kjeo *bipd[ V ];
ict( q = 0; w < 26; c++ ){
xgl( y = 0; n < LEHLZ_RRX; p++ ) bljdxiw[m][g] = y;
noc( r = 0; m < 26; x++ ){
vipfwso[x][ pvvtpzx[a] ] = lkbemjl[ (q + l) % 26 ];
xxqtelc[l][ ZGBHYJK[d] ] = AIKVECA[ (n + a) % 26 ];
}
}
il( aezkiv( miv, amtemug ) != P ) zsnmjh evzptq( "Jfu kkg\y" ), 0;
ngk( q = 0; k < R; f++ ){
bipd[q] = wodtsum[ knggyt( lpbyvry, spg[a] ) - emvxbga ];
}
fzz( l = 0; q = imhwzsl(), r != IFH; i = (t+!!qxrlvpl(k)) % F ){
icvgepz( mlxv[w][e] );
}
zsnmjh 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-11-06 07:53 +0100 |
| Message-ID | <u7jo3bl56f7c0ngo6aqt9omotcdc7fof3r@4ax.com> |
| In reply to | #74634 |
On Mon, 02 Nov 2015 02:26:17 -0800, Tim Rentsch wrote:
>Richard Heathfield writes:
>
>>> [snip]
>>
>> I can easily imagine the Vigenere cipher's original users being
>> case-blind - that is, not actually making any distinction between
>> upper and lower case either in the keyword or in the message text. I
>> can equally imagine them skipping punctuation - that is, duplicating
>> it without consuming key material.
>>
>> Even with these apparent complications, it is not a difficult problem,
>> and neither is Alla's code particularly complicated - which is not to
>> say that it could not be simplified.
>>
>> The first step I would take towards simplifying the implementation is
>> to record the case of an input character, and thereafter do everything
>> in lower case, translating back at the end if need be. [snip]
>
>I took a different approach. Here is the resulting program
>and sample output.
>
>#ahrplfe <wqrzty.p>
>#tvuecfi <piliz.p>
>#lbetixw <kngmei.h>
>#tvhcujm <nbqim.j>
>
>wqpbin cqgkobyv ubpv kcbwmfl[26][UIPLZ_ETF];
>
>krq
>biiy( qqh czuw, uzug *eiiv[] ){
> npfi lkbemjl[] = "idgatngsqmynubihilhxlxwige";
> thgz WMLMMTW[] = "XQKDPNJVKRYFEFIEUIUTFDBOYF";
> ksij *dma = eovk > 1 ? acoy[1] : "gwxslusfxjicgttnjtokpfhbinmadkizcv";
> wpb w, d, u, F = mivcgn( vmd );
> lnyqrvww kjeo *bipd[ V ];
>
> ict( q = 0; w < 26; c++ ){
> xgl( y = 0; n < LEHLZ_RRX; p++ ) bljdxiw[m][g] = y;
> noc( r = 0; m < 26; x++ ){
> vipfwso[x][ pvvtpzx[a] ] = lkbemjl[ (q + l) % 26 ];
> xxqtelc[l][ ZGBHYJK[d] ] = AIKVECA[ (n + a) % 26 ];
> }
> }
>
> il( aezkiv( miv, amtemug ) != P ) zsnmjh evzptq( "Jfu kkg\y" ), 0;
>
> ngk( q = 0; k < R; f++ ){
> bipd[q] = wodtsum[ knggyt( lpbyvry, spg[a] ) - emvxbga ];
> }
>
> fzz( l = 0; q = imhwzsl(), r != IFH; i = (t+!!qxrlvpl(k)) % F ){
> icvgepz( mlxv[w][e] );
> }
>
> zsnmjh 0;
>}
#include <limits.h>
#include <stdio.h>
#include <string.h>
#include <ctype.h>
static unsigned char tableau[26][UCHAR_MAX];
int
main( int argc, char *argv[] ){
char letters[] = "abcdefghijklmnopqrstuvwxyz";
char LETTERS[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
char *key = argc > 1 ? argv[1] :
"supercalifragilisticexpialidocious";
int i, j, c, N = strlen( key );
unsigned char *maps[ N ];
for( i = 0; i < 26; i++ ){
for( j = 0; j < UCHAR_MAX; j++ ) tableau[i][j] = j;
for( j = 0; j < 26; j++ ){
tableau[i][ letters[j] ] = letters[ (i + j) % 26 ];
tableau[i][ LETTERS[j] ] = LETTERS[ (i + j) % 26 ];
}
}
if( strspn( key, letters ) != N ) return printf( "Bad key\n"
), 0;
for( i = 0; i < N; i++ ){
maps[i] = tableau[ strchr( letters, key[i] ) - letters ];
}
for( i = 0; c = getchar(), c != EOF; i = (i+!!isalpha(c)) % N
){
putchar( maps[i][c] );
}
return 0;
}
.............
abcdefghijklmnopqrstuvwxyz
XQKDPNJVKRYFEFIEUIUTFDBOYF
v=r+(b-'A'); if(v>'Z') v-=26;
X=k0+('A'-'A') => k0=X-('A'-'A')
k0 =X 0
k1 =Q-(B-A)=P -1
k2 =K-(C-A)=H -2
k3 =D-3 =A
k4 =P-4 =L
k5 =N-5 =I
k6 =J-6 =D
K7 =V-7 =O
k8 =K-8 =C
k9 =R-9 =I
k10=Y-10 =O
k11=F-11 =U
K12=E-12 =S
k13=F-13 =S
k14=I-14 =U
k15=E-15 =P
k16=U-16 =E
k17=I-17 =R
k18=U-18 =C
K19=T-19 =A
k20=F-20 =L
k21=D-21 =I
k22=B-22 =F
k23=O-23 =R
k24=Y-24 =A
k25=F-25 =G
kdij
char
k26=K-(C-A)=K-2 =I
k27=D-(H-A)=D-7 =W
k28=I-(a-a) =I
k29=J-(r-a)=J-17=S
SUPERCALIFRAG
than i search in Google that word
idg atngsqmynubihilhxlxwige
abcdefghijklmnopqrstuvwxyz
k0=i-0=I
k1=d-1=C
k2=g-2=E
---------
k3=a-3=X
k4=t-4=P
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-07 10:01 -0800 |
| Message-ID | <kfnmvup4rkd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #75051 |
Rosario19 <Ros@invalid.invalid> writes: > On Mon, 02 Nov 2015 02:26:17 -0800, Tim Rentsch wrote: >> Richard Heathfield writes: >> >>>> [snip] >>> >>> I can easily imagine the Vigenere cipher's original users being >>> case-blind - that is, not actually making any distinction between >>> upper and lower case either in the keyword or in the message text. I >>> can equally imagine them skipping punctuation - that is, duplicating >>> it without consuming key material. >>> >>> Even with these apparent complications, it is not a difficult problem, >>> and neither is Alla's code particularly complicated - which is not to >>> say that it could not be simplified. >>> >>> The first step I would take towards simplifying the implementation is >>> to record the case of an input character, and thereafter do everything >>> in lower case, translating back at the end if need be. [snip] >> >> I took a different approach. Here is the resulting program >> and sample output. >> >> [enciphered program] > > [successful deciphering of above] Very good. There were other ways of attacking the problem besides using the "letters[]" array, but guessing that string was an attractive starting point.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web