The Huge Significance of the Vigenere Cipher in modern Cryptography. [Cryptography]

Prev: Polymorphic Code Protection
Next: Dutch clearly robbed of victory by not giving a crucial/obvious corner near the end of the match, putting the defense offguard resulting in a counter-goal.

From: adacrypt on 14 Jul 2010 05:49

On Jul 12, 5:31 pm, rossum <rossu...(a)coldmail.com> wrote:
> On Mon, 12 Jul 2010 03:41:58 -0700 (PDT), adacrypt
>
> <austin.oby...(a)hotmail.com> wrote:
> >The Vigenere Cipher in the year circa 1586 was an exception and it
> >took cryptography into two dimensions for the first time albeit its
> >inventor could not possibly have foreseen that his invention was to
> >have a profound effect on future cryptography in the 21st century that
> >uses the ASCII printable subset 32 to 126 inclusive, to populate the
> >eponymous square that is at the heart of that cipher instead of the 26
> >letter characters of the English language.
>
> There is nothing preventing you from applying your ideas about using
> the Vigenère square in a 256 x 256 form so it can cover all possible
> bytes, not just a subset of them. As it is your system is not
> guaranteed to reproduce what was initially put into it. For example,
> here is a short Java program:
>
> public class MyMain {
> public static void main(String[] args) {
> System.out.println("Hello world!");
> }
>
> }
>
> This program compiles and runs correctly. Since your system does not
> recognise linefeeds for encryption and on decryption inserts new
> linefeeds IIRC every 77 characters, the output from your system would
> look like:
>
> public class MyMain { public static void main(String[] args) {
> System.ou
> t.println("Hello world!"); }}
>
> That no longer compiles correctly because "System.ou" is not
> recognised. Your proposal cannot guarantee that what emerges is
> identical to what is put in. That is a major failing in a proposed
> cryptography system.
>
> Using a 256 x 256 Vigenère would avoid this problem.
>
> rossum

Hi ,
>This program compiles and runs correctly. Since your system does not
>recognise linefeeds for encryption and on decryption inserts new
>linefeeds IIRC every 77 characters, the output from your system would
>look like:
This is an ongoing albeit unimportant issue in your previous posts
that might benefit me from open discussion. To the best of my
knowledge the compiler instructs the operating system of any computer
to automatically limit line lenghts (internally) to 255 characters and
marks it with some character from the full set of ASCII as End-of-
Line. Attempting to regulate line lenghts externally is ineffectual
on what the computer does internally. End-of File is also marked
similarly. I am sure that these terms i.e. End-of File and End-of-
Line are properties of the compiler and not the operating system.

Two things follow:

Firstly, I cannot and must not use the full set of ASCII to populate
the Vigenere square as you suggest because the computer may then end
the line or the file prematurely if it reads a the terminating marker
amomng the ciphertext.

Secondly, In my cryptography I use any line length (I have said 77
characters in previous posts but that is just a nominal figure - it
may be anything else within reason) to limit the displayed output line
length with the standard command in Ada "Set_Line_Length(X)". The
computer then gives me that line length but admittedly it means broken
words at the ends. I am not bothered about this because I can
immediately open the file of messagetext in any word processor when it
will immmediately justify all words to be complete and align them
either by the right edge or the left edge or symmetrically abiut the
about centre line as you wel realise I am sure. It is fuitle to
expect or even try to make the compiler or the operating system to do
this when it is so easil done in other software that is designed
specially for that purpose.

I am open to correction here if I am wrong but please explain - cheers
- adacrypt

From: adacrypt on 14 Jul 2010 08:03

On Jul 14, 11:16 am, Mark Murray <w.h.o...(a)example.com> wrote:
> On 07/14/10 10:49, adacrypt wrote:
>
> > I am open to correction here if I am wrong but please explain - cheers
> > - adacrypt
>
> You ARE wrong. The reasons why have been explained to you /ad nauseam/.
> What reason exists that explaining it yet again will make one iota of
> difference?
>
> M
> --

Oh dear ! - adacrypt

From: rossum on 14 Jul 2010 09:37

On Mon, 12 Jul 2010 12:58:05 -0500, gordonb.76k3z(a)burditt.org (Gordon
Burditt) wrote:

>"The Huge Significance of the Bow and Arrow in Modern Cooking"?
As Mrs Beeton said, "First catch your rabbit."

rossum

From: adacrypt on 14 Jul 2010 09:46

On Jul 14, 2:35 pm, rossum <rossu...(a)coldmail.com> wrote:
> On Wed, 14 Jul 2010 02:49:09 -0700 (PDT), adacrypt
>
> <austin.oby...(a)hotmail.com> wrote:
> >I am open to correction here if I am wrong but please explain
>
> You are trying to do two separate things in one process:
> encryption/decryption and armouring.
>
> Encryption/decryption takes some bytes and transforms then to some
> different bytes. This process deals exclusively with bytes. It knows
> nothing about ASCII, EBCDIC, Unicode or whatever. It has no concept
> of "text", "line", "file" or whatever. The process takes an array (or
> possibly a stream) of bytes and outputs an array/stream of bytes.
>
> byte[] cyphertext = encrypt(byte[] plaintext);
>
> Decrypting is the same:
>
> byte[] plaintext = decrypt(byte[] cyphertext);
>
> The second thing you are trying to do is "armouring", which is a
> process that allows raw bytes to be transmitted through a text based
> system. This is where your point about line feeds and EoF markers
> appearing in the cyphertext is valid. The standard solution is to
> transform the raw bytes into a subset of the printable Unicode
> characters. The usual method is Base64, though Base 32 and Base16
> (aka Hex) are sometimes used. RFC 3548 covers all three in great
> detail.
>
> I very strongly suggest that you do not try to mix these two separate
> processes. The armouring is not needed if you are not outputting to a
> text file or to a text stream. A binary file, or stream, does not
> need armouring. Only apply the armouring where it is needed. Your
> current proposal enforces a non-standard form of armouring on all
> users, whether they need it or not. Use a standard armouring,
> preferably Base64, and make it optional.
>
> Here is an ASCII diagram:
>
> original-data
> |
> V
> bytes
> |
> V
> encrypt
> |
> V
> encrypted-bytes
> | |
> | V
> | armouring
> | |
> V V
> binary-file text-file
>
> rossum

From: adacrypt on 14 Jul 2010 09:47

First | Prev | Next | Last
Pages: 1 2 3
Prev: Polymorphic Code Protection
Next: Dutch clearly robbed of victory by not giving a crucial/obvious corner near the end of the match, putting the defense offguard resulting in a counter-goal.