* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-03 20:48 ` Austin Obyrne
@ 2014-12-03 20:57 ` Pascal Obry
2014-12-03 22:39 ` mrvmurray
2014-12-03 22:29 ` mrvmurray
` (3 subsequent siblings)
4 siblings, 1 reply; 27+ messages in thread
From: Pascal Obry @ 2014-12-03 20:57 UTC (permalink / raw)
Le mercredi 03 décembre 2014 à 12:48 -0800, Austin Obyrne a écrit :
> Current cryptography is capable of encrypting ASCII and at most the
> entire Latin-1 set. There is a vast set of mathematical symbols,
> special general characters, Greek language characters (often included
> in English language test files)that cannot be read in or keyed for
> encryption because they are outside of the Latin_1 character set.
I don't understand, but I'm no expert. To me cryptography is based on
stream of bytes. So it can encode anything that is stored on disk or any
memory region of our computer.
So what do you mean by the above?
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.org
http://www.obry.net
gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-03 20:57 ` Pascal Obry
@ 2014-12-03 22:39 ` mrvmurray
0 siblings, 0 replies; 27+ messages in thread
From: mrvmurray @ 2014-12-03 22:39 UTC (permalink / raw)
On Wednesday, 3 December 2014 20:57:02 UTC, Pascal Obry wrote:
> So what do you mean by the above?
It is a long-standing misconception of his. In 10+ years he's been
unable to break away from the idea that plainTEXT can be anything
input to a cipher, and he's convinced that encryption is limited to
human-readable text. He has many similar misconceptions about
computers in general.
This is not helped by the fact that he only knows how to use the
ada.text_io and ada.integer_text_io packages, and has proven
himself aggressively hostile to attempting to use something more
suitable. He is similarly hostile to bug reports in his code.
Thus, his cipher will only encrypt (badly, mind you) bytes in the
numeric range 32..126. Newlines are passed through unchanged
and other bytes cause his program to crash.
M
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-03 20:48 ` Austin Obyrne
2014-12-03 20:57 ` Pascal Obry
@ 2014-12-03 22:29 ` mrvmurray
2014-12-03 22:34 ` Denis McMahon
` (2 subsequent siblings)
4 siblings, 0 replies; 27+ messages in thread
From: mrvmurray @ 2014-12-03 22:29 UTC (permalink / raw)
On Wednesday, 3 December 2014 20:48:24 UTC, Austin Obyrne wrote:
> Current cryptography is capable of encrypting ASCII and at
> most the entire Latin-1 set. There is a vast set of mathematical
> symbols, special general characters, Greek language characters
> (often included in English language test files)that cannot be read
> in or keyed for encryption because they are outside of the Latin_1
> character set. Nor is there any formatting facilities in the current
> ciphers and as far as I know message text must be formatted at
> the receiving end when is should be done beforehand at the sending
> end.
Wrong. Modern crypto can encrypt anything, without needing to
know anything about what it is. It cares not a jot about any structure
of the content.
Likewise, Ada programs can read anything, without needing to know
what it is. It's only when there is a need to understand the structure
of the data that further processing is required, and an encryption
program does not need this understanding.
M
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-03 20:48 ` Austin Obyrne
2014-12-03 20:57 ` Pascal Obry
2014-12-03 22:29 ` mrvmurray
@ 2014-12-03 22:34 ` Denis McMahon
2014-12-04 8:26 ` Austin Obyrne
2014-12-04 3:41 ` Dennis Lee Bieber
2014-12-04 15:25 ` Simon Wright
4 siblings, 1 reply; 27+ messages in thread
From: Denis McMahon @ 2014-12-03 22:34 UTC (permalink / raw)
On Wed, 03 Dec 2014 12:48:19 -0800, Austin Obyrne wrote:
> Current cryptography is capable of encrypting ASCII and at most the
> entire Latin-1 set.
Wrong. Current cryptography is capable of encrypting any bit stream. As
any file can be presented as a bit stream, this means that current
cryptography can encrypt any file. This includes all symbols, and any
other data that can be encoded into a file using any character set
encoding that you care to use. Korean, Mandarin, Cyrillic, Greek, Hebrew,
Arabic, they can all be encoded electronically in files using appropriate
character encoding and the files can be encrypted, as can audio files,
images, movies, anything that can be represented as a stream of bits.
So your basic premise, that there is some arbitrary restriction of
current encryption to a specific character set is fundamentally wrong!
--
Denis McMahon, denismfmcmahon@gmail.com
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-03 22:34 ` Denis McMahon
@ 2014-12-04 8:26 ` Austin Obyrne
2014-12-04 8:37 ` mrvmurray
2014-12-04 23:38 ` Shark8
0 siblings, 2 replies; 27+ messages in thread
From: Austin Obyrne @ 2014-12-04 8:26 UTC (permalink / raw)
On Wednesday, December 3, 2014 10:35:03 PM UTC, Denis McMahon wrote:
> On Wed, 03 Dec 2014 12:48:19 -0800, Austin Obyrne wrote:
>
> > Current cryptography is capable of encrypting ASCII and at most the
> > entire Latin-1 set.
>
> Wrong. Current cryptography is capable of encrypting any bit stream. As
> any file can be presented as a bit stream, this means that current
> cryptography can encrypt any file. This includes all symbols, and any
> other data that can be encoded into a file using any character set
> encoding that you care to use. Korean, Mandarin, Cyrillic, Greek, Hebrew,
> Arabic, they can all be encoded electronically in files using appropriate
> character encoding and the files can be encrypted, as can audio files,
> images, movies, anything that can be represented as a stream of bits.
>
> So your basic premise, that there is some arbitrary restriction of
> current encryption to a specific character set is fundamentally wrong!
>
> --
> Denis McMahon, denismfmcmahon@gmail.com
Yes - what you say is definitively true if you mean using Unicode - I had in mind the average user who wants to spontaneously encrypt on a handheld tablet during a lunch break say.
Playing with semantics doesn't hide the fact that many cryptographers are just playing with the box that other peoples' thoughts comes in and just cannot write ciphers of their own.
adacrypt
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-04 8:26 ` Austin Obyrne
@ 2014-12-04 8:37 ` mrvmurray
2014-12-04 23:38 ` Shark8
1 sibling, 0 replies; 27+ messages in thread
From: mrvmurray @ 2014-12-04 8:37 UTC (permalink / raw)
On Thursday, 4 December 2014 08:26:57 UTC, Austin Obyrne wrote:
> Yes - what you say is definitively true if you mean using Unicode ...
NO.
He does not mean Unicode. He means a totally arbitrary sequence of bits
with absolutely no assumption of their meaning whatsoever.
M
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-04 8:26 ` Austin Obyrne
2014-12-04 8:37 ` mrvmurray
@ 2014-12-04 23:38 ` Shark8
1 sibling, 0 replies; 27+ messages in thread
From: Shark8 @ 2014-12-04 23:38 UTC (permalink / raw)
On Wednesday, December 3, 2014 10:35:03 PM UTC, Denis McMahon wrote:
> Wrong. Current cryptography is capable of encrypting any bit stream.
>> On 04-Dec-14 01:26, Austin Obyrne wrote:
>> Yes - what you say is definitively true if you mean using Unicode
No, it's true in any case; for any collection of of bits.
Here's an example using nybbles (encoded as 1..16):
procedure Test is
Type Nybble is range 1..16 with Size => 4;
Type Nybble_Array is Array(Positive range <>) of Nybble with Pack,
Component_Size => Nybble'Size;
function "XOR" (Left, Right : Nybble) return Nybble is
Type Bool_Array is array(1..4) of Boolean
with Pack, Component_Size => 1, Size => 4;
L : Bool_Array with Import, Address => Left'Address;
R : Bool_Array with Import, Address => Right'Address;
begin
Return Result : Nybble do
declare
X : Bool_Array with Import, Address => Result'Address;
begin
X:= L xor R;
end;
end return;
end "XOR";
Procedure Print( Data : Nybble_Array ) is
begin
for N of Data loop
Ada.Text_IO.Put( N'Img );
end loop;
end Print;
Function Encrypt( Data : Nybble_Array;
Encryption_Key : in Nybble
) return Nybble_Array is
begin
Return Result : Nybble_Array(Data'Range) do
for Index in Data'Range loop
declare
Datum : Nybble renames Data(Index);
begin
-- A simple "encryption".
Result(Index):= Datum xor Encryption_Key;
end;
end loop;
end return;
end Encrypt;
Function Decrypt( Data : Nybble_Array;
Decryption_Key : in Nybble
) return Nybble_Array
renames Encrypt;
Test_Data : Nybble_Array:= (1, 11, 13, 4, 2, 7);
use Ada.Text_IO;
begin
declare
Encode_Key : Nybble := 2#1101#;
Encoded : Nybble_Array:= Encrypt(Test_Data, Encode_Key);
begin
Put( "Test Data:" & ASCII.HT );
Print(Test_Data);
New_Line(2);
Put( "Encoded (" & Encode_Key'Img & " )" & ASCII.HT );
Print(Encoded);
New_Line(2);
Put( "Decoded (" & Encode_Key'Img & " )" & ASCII.HT );
Print( Decrypt(Encoded, Encode_Key) );
New_Line(2);
end;
Ada.Text_IO.Put_Line( "Done." );
end Test;
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-03 20:48 ` Austin Obyrne
` (2 preceding siblings ...)
2014-12-03 22:34 ` Denis McMahon
@ 2014-12-04 3:41 ` Dennis Lee Bieber
2014-12-05 7:04 ` Nasser M. Abbasi
2014-12-04 15:25 ` Simon Wright
4 siblings, 1 reply; 27+ messages in thread
From: Dennis Lee Bieber @ 2014-12-04 3:41 UTC (permalink / raw)
On Wed, 3 Dec 2014 12:48:19 -0800 (PST), Austin Obyrne
<austin.obyrne@hotmail.com> declaimed the following:
>Current cryptography is capable of encrypting ASCII and at most the entire Latin-1 set. There is a vast set of mathematical symbols, special general characters, Greek language characters (often included in English language test files)that cannot be read in or keyed for encryption because they are outside of the Latin_1 character set. Nor is there any formatting facilities in the current ciphers and as far as I know message text must be formatted at the receiving end when is should be done beforehand at the sending end.
>
WRONG... In the source file, all those characters, et al, are
represented by some stream of bytes... And all proper encryption systems
work with bytes or blocks thereof (doesn't DES use 64-bits at a time?).
Encryption systems don't care what the data is, they just transform it in
some reversible means.
>All of the foregoing can be done by deploying latex which is always entirely ASCII and can be encrypted as ASCII while possessing all sorts of non-ASCII attributes in its command code. The input file of latex is encrypted in ASCII - the file may be encrypted and when it is decrypted it can be run so as to typeset the message in any way the entities want. There is also a vast amount of extra prose that is outside of the scope of ASCII for the benefit of users. These are the perceived benefits of using Latex as an encryption platform in conjunction.
>
LaTeX is nothing more than ONE typesetting program... One that just
happens to use plain ASCII as the native user interface (no surprise -- it
predates all the WIMP computers that came out in the mid-80s)... M$ Word,
for many years, has included an equation writer module which allows one to
create mathematical texts... A Word doc(x) file can be encrypted,
transferred to others, decrypted, and loaded into Word for generation of
typeset output...
LaTeX is a language for laying out documents... So were the various
roff/troff/etc., RTF, and PostScript... All are plain text files that rely
upon some rendering engine to produce the final output form. Your LaTeX
file, regardless of any mysticism of encryption/decryption, is nothing
without the LaTeX processor (and most LaTeX environment these days just
translate the LaTeX source into PostScript page descriptions, passing that
off to GhostScript to be rendered on some printer -- presuming the printer
itself doesn't have a PostScript RIP built-in.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-04 3:41 ` Dennis Lee Bieber
@ 2014-12-05 7:04 ` Nasser M. Abbasi
2014-12-05 16:59 ` Dennis Lee Bieber
0 siblings, 1 reply; 27+ messages in thread
From: Nasser M. Abbasi @ 2014-12-05 7:04 UTC (permalink / raw)
On 12/3/2014 9:41 PM, Dennis Lee Bieber wrote:
> is nothing
> without the LaTeX processor (and most LaTeX environment these days just
> translate the LaTeX source into PostScript page descriptions, passing that
> off to GhostScript to be rendered on some printer -- presuming the printer
> itself doesn't have a PostScript RIP built-in.
>
Actually hardly anyone uses poscript (dvips) now. It is all pdflatex.
postscript documents are pretty much dead.
--Nasser
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-05 7:04 ` Nasser M. Abbasi
@ 2014-12-05 16:59 ` Dennis Lee Bieber
0 siblings, 0 replies; 27+ messages in thread
From: Dennis Lee Bieber @ 2014-12-05 16:59 UTC (permalink / raw)
On Fri, 05 Dec 2014 01:04:23 -0600, "Nasser M. Abbasi" <nma@12000.org>
declaimed the following:
>
>Actually hardly anyone uses poscript (dvips) now. It is all pdflatex.
>postscript documents are pretty much dead.
>
And PDF is, at heart, a variation of PostScript -- as I recall, the
original difference mostly came down to changing the long operator/function
names of PostScript to shorter acronyms/abbreviation.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-03 20:48 ` Austin Obyrne
` (3 preceding siblings ...)
2014-12-04 3:41 ` Dennis Lee Bieber
@ 2014-12-04 15:25 ` Simon Wright
2014-12-04 16:31 ` Austin Obyrne
2014-12-05 13:02 ` Austin Obyrne
4 siblings, 2 replies; 27+ messages in thread
From: Simon Wright @ 2014-12-04 15:25 UTC (permalink / raw)
Austin Obyrne <austin.obyrne@hotmail.com> writes:
> Current cryptography is capable of encrypting ASCII and at most the
> entire Latin-1 set.
Looking back on Google I see that on 16 December 2013 I posted
https://groups.google.com/d/msg/comp.lang.ada/qJ5vpRQarSQ/QNvyYgYVjewJ
which I've copied below.
So a year ago I demonstrated that
- minor tweaks will enable your code to:
- deal with data on Windows and Unix systems and to transfer data
between them, and
- deal with binary data,
- but the cipertext is >30 times the size of the original (because you
encode each byte of the input as 3 integers, represented as text).
These are practical matters and have nothing to do with the validity of
the encryption technology.
========================================================================
Austin Obyrne <austin...@hotmail.com> writes:
> The transition of this crypto from Windows to Mac is quite something
> and to my limited experience is a formidable task.
No.
I've put extensions at [1]; the README.txt says
------------------------------------------------------------------------
The files here are intended to work with the SureCrypt software from
http://www.adacryptpages.com. They are written against version 85610,
and are relatively minor modifications of that software, so the
copyright status remains that of the original (Copyright © 2003 Austin
O'Byrne).
There are two new programs: encrypt and decrypt.
Encrypt usage:
encrypt original-plaintext ciphertext
Decrypt usage:
decrypt ciphertext decrypted-plaintext
Note that in spite of the use of the word "text" above the programs
will work with binary data.
The programs will work on Unix and Windows systems. Data encrypted on
one can be decrypted on the other if required.
Using a recent GNAT compiler, the programs can be built using the
supplied cipher.gpr:
gnatmake -p -P cipher
Simon Wright
si...@pushface.org
December 2013
------------------------------------------------------------------------
From the software point of view, note that on Linux (which has a
case-sensitive file system) you should use lower case for Ada source
file names, so that, for example, Alices_Digital_Signature.ads becomes
alices_digital_signature.ads.
From the practical point of view, I think that the size of the encrypted
files will be a serious issue. With the current code, they come out
*more* *than* *30* *times* the size of the original, so that the
encrypted SureCrypt85610.zip comes out at about 870 megabytes. Even if
you output the encrypted data in binary the multiplier will be 12 (each
byte of the original is encrypted as 3 integers).
[1] https://www.dropbox.com/sh/a84i0jb8jv48nev/Q143ubNUWC
========================================================================
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-04 15:25 ` Simon Wright
@ 2014-12-04 16:31 ` Austin Obyrne
2014-12-04 18:24 ` Austin Obyrne
2014-12-05 8:21 ` mrvmurray
2014-12-05 13:02 ` Austin Obyrne
1 sibling, 2 replies; 27+ messages in thread
From: Austin Obyrne @ 2014-12-04 16:31 UTC (permalink / raw)
On Thursday, December 4, 2014 3:25:46 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
>
> > Current cryptography is capable of encrypting ASCII and at most the
> > entire Latin-1 set.
>
> Looking back on Google I see that on 16 December 2013 I posted
> https://groups.google.com/d/msg/comp.lang.ada/qJ5vpRQarSQ/QNvyYgYVjewJ
> which I've copied below.
>
> So a year ago I demonstrated that
>
> - minor tweaks will enable your code to:
>
> - deal with data on Windows and Unix systems and to transfer data
> between them, and
>
> - deal with binary data,
>
> - but the cipertext is >30 times the size of the original (because you
> encode each byte of the input as 3 integers, represented as text).
>
> These are practical matters and have nothing to do with the validity of
> the encryption technology.
>
> ========================================================================
> Austin Obyrne <austin...@hotmail.com> writes:
>
> > The transition of this crypto from Windows to Mac is quite something
> > and to my limited experience is a formidable task.
>
> No.
>
> I've put extensions at [1]; the README.txt says
>
> ------------------------------------------------------------------------
> The files here are intended to work with the SureCrypt software from
> http://www.adacryptpages.com. They are written against version 85610,
> and are relatively minor modifications of that software, so the
> copyright status remains that of the original (Copyright © 2003 Austin
> O'Byrne).
>
> There are two new programs: encrypt and decrypt.
>
> Encrypt usage:
>
> encrypt original-plaintext ciphertext
>
> Decrypt usage:
>
> decrypt ciphertext decrypted-plaintext
>
> Note that in spite of the use of the word "text" above the programs
> will work with binary data.
>
> The programs will work on Unix and Windows systems. Data encrypted on
> one can be decrypted on the other if required.
>
> Using a recent GNAT compiler, the programs can be built using the
> supplied cipher.gpr:
>
> gnatmake -p -P cipher
>
> Simon Wright
> si...@pushface.org
> December 2013
> ------------------------------------------------------------------------
>
> From the software point of view, note that on Linux (which has a
> case-sensitive file system) you should use lower case for Ada source
> file names, so that, for example, Alices_Digital_Signature.ads becomes
> alices_digital_signature.ads.
>
> From the practical point of view, I think that the size of the encrypted
> files will be a serious issue. With the current code, they come out
> *more* *than* *30* *times* the size of the original, so that the
> encrypted SureCrypt85610.zip comes out at about 870 megabytes. Even if
> you output the encrypted data in binary the multiplier will be 12 (each
> byte of the original is encrypted as 3 integers).
>
> [1] https://www.dropbox.com/sh/a84i0jb8jv48nev/Q143ubNUWC
> ========================================================================
Hi Simon,
Thanks for that really useful feedback.
Can I say that everything to date with my cryptography (and there has been much refinement in the meantime) should be seen as exploratory - My dogma is that when the core mathematical algorithm is irreversibly intractable only then will I entertain any studies or listen to any criticism of the management. I accept that there is much room for criticism and improvement but that does not bother me - there are millions of people out there who have the wherewithal to hone a rough diamond that my ciphers are into a super duper one.
I contend my forte is in writing (a few) such ciphers that people like yourself will be able to fine tune them when the mathematics irrefutably show that it is complete. I can reduce that ratio i.e. a ciphertext expansion ratio of 26 to 1 (a bit less than you say) to as much as about 10 to 1 quite easily myself just off the top of my head.
The same goes for the efficacy of my Ada-95 programming. I do worry what that looks like to anybody - I have written some procedures that are truly elegant as problem solving methods but I won't deny that to an Ada specialist there must be huge room for improvement. Again I leave that to other experts.
In passing, I loathe, hate and , despise what I call 'flash Harry programmers who thiink it is smart to confuse people with minimalised source code - That is why I always iuse Ada.Text_IO when a 'Use' would do the same.
*Apart from the defunct One-Time pad cipher there is no unbreakable cipher in the world today - not RSA not AES they are only what is called "Practically unbreakable" and may be blown away if Quantum Computing ever materialises - My stuff is a *world first in the ultimate class of "theoretically Unbreakable" cryptographic strength. I can demonstrate three ciphers in this highest class class and NB one of them has the optimum ciphertext expansion ratio of about 6 to 1 - it is not a problem.
Much is made of the peripheral management aspect of my crypto by disgruntled readers who say it is not coming in the box that are used to but let me put this challenge to anybody out there.
Accept that the ultimate strength of any cipher depends on the core algorithm and that any management defects can be marked *proved but repairable then fast track to the frontier with your operand and ignoring the warts 'n all of the cipher management (which cuts no ice really)show how your encryption of a number into another number is done in a way that is selectively reversible by only two people on this planet.
Go for it mate - you would eat your computer before you get as far as I have.
adacrypt,
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-04 16:31 ` Austin Obyrne
@ 2014-12-04 18:24 ` Austin Obyrne
2014-12-05 8:21 ` mrvmurray
1 sibling, 0 replies; 27+ messages in thread
From: Austin Obyrne @ 2014-12-04 18:24 UTC (permalink / raw)
On Thursday, December 4, 2014 4:31:36 PM UTC, Austin Obyrne wrote:
> On Thursday, December 4, 2014 3:25:46 PM UTC, Simon Wright wrote:
> > Austin Obyrne <austin.obyrne@hotmail.com> writes:
> >
> > > Current cryptography is capable of encrypting ASCII and at most the
> > > entire Latin-1 set.
> >
> > Looking back on Google I see that on 16 December 2013 I posted
> > https://groups.google.com/d/msg/comp.lang.ada/qJ5vpRQarSQ/QNvyYgYVjewJ
> > which I've copied below.
> >
> > So a year ago I demonstrated that
> >
> > - minor tweaks will enable your code to:
> >
> > - deal with data on Windows and Unix systems and to transfer data
> > between them, and
> >
> > - deal with binary data,
> >
> > - but the cipertext is >30 times the size of the original (because you
> > encode each byte of the input as 3 integers, represented as text).
> >
> > These are practical matters and have nothing to do with the validity of
> > the encryption technology.
> >
> > ========================================================================
> > Austin Obyrne <austin...@hotmail.com> writes:
> >
> > > The transition of this crypto from Windows to Mac is quite something
> > > and to my limited experience is a formidable task.
> >
> > No.
> >
> > I've put extensions at [1]; the README.txt says
> >
> > ------------------------------------------------------------------------
> > The files here are intended to work with the SureCrypt software from
> > http://www.adacryptpages.com. They are written against version 85610,
> > and are relatively minor modifications of that software, so the
> > copyright status remains that of the original (Copyright © 2003 Austin
> > O'Byrne).
> >
> > There are two new programs: encrypt and decrypt.
> >
> > Encrypt usage:
> >
> > encrypt original-plaintext ciphertext
> >
> > Decrypt usage:
> >
> > decrypt ciphertext decrypted-plaintext
> >
> > Note that in spite of the use of the word "text" above the programs
> > will work with binary data.
> >
> > The programs will work on Unix and Windows systems. Data encrypted on
> > one can be decrypted on the other if required.
> >
> > Using a recent GNAT compiler, the programs can be built using the
> > supplied cipher.gpr:
> >
> > gnatmake -p -P cipher
> >
> > Simon Wright
> > si...@pushface.org
> > December 2013
> > ------------------------------------------------------------------------
> >
> > From the software point of view, note that on Linux (which has a
> > case-sensitive file system) you should use lower case for Ada source
> > file names, so that, for example, Alices_Digital_Signature.ads becomes
> > alices_digital_signature.ads.
> >
> > From the practical point of view, I think that the size of the encrypted
> > files will be a serious issue. With the current code, they come out
> > *more* *than* *30* *times* the size of the original, so that the
> > encrypted SureCrypt85610.zip comes out at about 870 megabytes. Even if
> > you output the encrypted data in binary the multiplier will be 12 (each
> > byte of the original is encrypted as 3 integers).
> >
> > [1] https://www.dropbox.com/sh/a84i0jb8jv48nev/Q143ubNUWC
> > ========================================================================
>
> Hi Simon,
>
> Thanks for that really useful feedback.
>
> Can I say that everything to date with my cryptography (and there has been much refinement in the meantime) should be seen as exploratory - My dogma is that when the core mathematical algorithm is irreversibly intractable only then will I entertain any studies or listen to any criticism of the management. I accept that there is much room for criticism and improvement but that does not bother me - there are millions of people out there who have the wherewithal to hone a rough diamond that my ciphers are into a super duper one.
>
> I contend my forte is in writing (a few) such ciphers that people like yourself will be able to fine tune them when the mathematics irrefutably show that it is complete. I can reduce that ratio i.e. a ciphertext expansion ratio of 26 to 1 (a bit less than you say) to as much as about 10 to 1 quite easily myself just off the top of my head.
>
> The same goes for the efficacy of my Ada-95 programming. I do worry what that looks like to anybody - I have written some procedures that are truly elegant as problem solving methods but I won't deny that to an Ada specialist there must be huge room for improvement. Again I leave that to other experts.
>
> In passing, I loathe, hate and , despise what I call 'flash Harry programmers who thiink it is smart to confuse people with minimalised source code - That is why I always iuse Ada.Text_IO when a 'Use' would do the same.
>
> *Apart from the defunct One-Time pad cipher there is no unbreakable cipher in the world today - not RSA not AES they are only what is called "Practically unbreakable" and may be blown away if Quantum Computing ever materialises - My stuff is a *world first in the ultimate class of "theoretically Unbreakable" cryptographic strength. I can demonstrate three ciphers in this highest class class and NB one of them has the optimum ciphertext expansion ratio of about 6 to 1 - it is not a problem.
>
> Much is made of the peripheral management aspect of my crypto by disgruntled readers who say it is not coming in the box that are used to but let me put this challenge to anybody out there.
>
> Accept that the ultimate strength of any cipher depends on the core algorithm and that any management defects can be marked *proved but repairable then fast track to the frontier with your operand and ignoring the warts 'n all of the cipher management (which cuts no ice really)show how your encryption of a number into another number is done in a way that is selectively reversible by only two people on this planet.
>
> Go for it mate - you would eat your computer before you get as far as I have.
>
> adacrypt,
Further.
It must surely seem that vector cryptography which requires three integers for each item of ciphertext as the displacement analogue of a decimal number is prohibitive in future cryptography. That is a shortsighted view on what is a useful crypto reality.
However likely is it to happen and to what extent it will affect current cryptography is debatable but the possibility has to be addressed that Quantum Computing will materialise just as the computer itself came after much speculation last century.
It is good to know that there are alternatives in the locker should current ciphers be blown away as some informed people are saying may happen by the arrival of quantum computers.
A proper inspection of my vector cryptography will enable very large reductions in the ciphertext expansion ration just by deploying ordinary plane geometry of the algorithm a bit more efficiently. This requires liaison with the management designers at whatever time in the future. Much is possible by way of improvements that would only appear as pie in the sky defensive claims were they made now.
This vector cryptography is here to stay.
- after the revolution - Viva.
There is also unbreakable scalar cryptography in the locker that is secured by the principles of the 'partitioning function' in combinatrics.
adacrypt
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-04 16:31 ` Austin Obyrne
2014-12-04 18:24 ` Austin Obyrne
@ 2014-12-05 8:21 ` mrvmurray
2014-12-05 18:42 ` Denis McMahon
1 sibling, 1 reply; 27+ messages in thread
From: mrvmurray @ 2014-12-05 8:21 UTC (permalink / raw)
On Thursday, 4 December 2014 16:31:36 UTC, Austin Obyrne wrote:
> Hi Simon,
>
> Thanks for that really useful feedback.
... etc, including a followup, in which he contradicts himself, distances himself
from the help already supplied, and displays a total disregard for his audience.
This guy is an intractable crank. He's completely deluded himself with his own
bullshit.
M
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-04 15:25 ` Simon Wright
2014-12-04 16:31 ` Austin Obyrne
@ 2014-12-05 13:02 ` Austin Obyrne
2014-12-05 20:09 ` mrvmurray
1 sibling, 1 reply; 27+ messages in thread
From: Austin Obyrne @ 2014-12-05 13:02 UTC (permalink / raw)
On Thursday, December 4, 2014 3:25:46 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
>
> > Current cryptography is capable of encrypting ASCII and at most the
> > entire Latin-1 set.
>
> Looking back on Google I see that on 16 December 2013 I posted
> https://groups.google.com/d/msg/comp.lang.ada/qJ5vpRQarSQ/QNvyYgYVjewJ
> which I've copied below.
>
> So a year ago I demonstrated that
>
> - minor tweaks will enable your code to:
>
> - deal with data on Windows and Unix systems and to transfer data
> between them, and
>
> - deal with binary data,
>
> - but the cipertext is >30 times the size of the original (because you
> encode each byte of the input as 3 integers, represented as text).
>
> These are practical matters and have nothing to do with the validity of
> the encryption technology.
>
> ========================================================================
> Austin Obyrne <austin...@hotmail.com> writes:
>
> > The transition of this crypto from Windows to Mac is quite something
> > and to my limited experience is a formidable task.
>
> No.
>
> I've put extensions at [1]; the README.txt says
>
> ------------------------------------------------------------------------
> The files here are intended to work with the SureCrypt software from
> http://www.adacryptpages.com. They are written against version 85610,
> and are relatively minor modifications of that software, so the
> copyright status remains that of the original (Copyright © 2003 Austin
> O'Byrne).
>
> There are two new programs: encrypt and decrypt.
>
> Encrypt usage:
>
> encrypt original-plaintext ciphertext
>
> Decrypt usage:
>
> decrypt ciphertext decrypted-plaintext
>
> Note that in spite of the use of the word "text" above the programs
> will work with binary data.
>
> The programs will work on Unix and Windows systems. Data encrypted on
> one can be decrypted on the other if required.
>
> Using a recent GNAT compiler, the programs can be built using the
> supplied cipher.gpr:
>
> gnatmake -p -P cipher
>
> Simon Wright
> si...@pushface.org
> December 2013
> ------------------------------------------------------------------------
>
> From the software point of view, note that on Linux (which has a
> case-sensitive file system) you should use lower case for Ada source
> file names, so that, for example, Alices_Digital_Signature.ads becomes
> alices_digital_signature.ads.
>
> From the practical point of view, I think that the size of the encrypted
> files will be a serious issue. With the current code, they come out
> *more* *than* *30* *times* the size of the original, so that the
> encrypted SureCrypt85610.zip comes out at about 870 megabytes. Even if
> you output the encrypted data in binary the multiplier will be 12 (each
> byte of the original is encrypted as 3 integers).
>
> [1] https://www.dropbox.com/sh/a84i0jb8jv48nev/Q143ubNUWC
> ========================================================================
I value your feedback greatly to the extent that I am archiving it as evidence to others - Austin
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The enormous potential that programming LaTeX in Ada presents.
2014-12-05 13:02 ` Austin Obyrne
@ 2014-12-05 20:09 ` mrvmurray
0 siblings, 0 replies; 27+ messages in thread
From: mrvmurray @ 2014-12-05 20:09 UTC (permalink / raw)
On Friday, 5 December 2014 13:02:55 UTC, Austin Obyrne wrote:
> On Thursday, December 4, 2014 3:25:46 PM UTC, Simon Wright wrote:
:
:
> >
> > [1] https://www.dropbox.com/sh/a84i0jb8jv48nev/Q143ubNUWC
> > ========================================================================
>
> I value your feedback greatly to the extent that I am archiving it as evidence to others - Austin
Thats a very good move! :-)
Simon's demonstration of the ease with which your code can be converted to
read/write binary succinctly removes silly distractions like LaTeX from the
process.
It also removes a source of program crashes, which makes debugging the
rest easier (now the plaintext shouldn't crash the program, but you still have
an artificially short message length).
M
--
^ permalink raw reply [flat|nested] 27+ messages in thread