The enormous potential that programming LaTeX in Ada presents.

[Austin Obyrne]

Latex is a typesetting language that can be encrypted by an Ada program and then securely decrypted back to its LaTeX input file format at the receiving end.

Why do that?

The benefits emanating from this suggestion are that is that there is an enormous amount of extra prose available that is not directly available in ASCII and also, the decrypted messagetext (i.e. the text file being typeset by the LaTeX input file) can be run so as to format the ensuing text of the original document in any way the users wish.

The benefits of doing this are legion, entire drafts of books for publishing, legal documents, updates of things like clauses in contracts that must fit as copy and paste, etc. etc. A particular use is in formatting mathematically 'heavy' documents. Ada programs for embedded applications (like Rosetta, Har Har) can be sent by email (unlikely of course, rather than top-security trusted live courier). The possibilities are legion. Transmissions of important Ada program sourccode might also be considered as the subject of a LaTeX input file but most of all the possibility of extra Ada/Latex formatting packages

This might involve the invention of special LaTeX to Ada packages. The use of Latex with Ada is an interesting prospect in many ways that may there just for the finding by some entrepreneurial spirit.

I am curious to know if anybody has any special take on this that might either preclude or promote the idea. Don't let any grass grow under your feet if so.

adacrypt

[David Botton]

I am having a hard time understanding why this is an Ada issue and not a question on the uses of cryptography in general? Maybe your question more generalized would make more sense in a cryptographic forum.

David Botton

[Austin Obyrne]

On Tuesday, December 2, 2014 2:07:29 PM UTC, David Botton wrote:
> I am having a hard time understanding why this is an Ada issue and not a question on the uses of cryptography in general? Maybe your question more generalized would make more sense in a cryptographic forum.
>
> David Botton

Point taken David,

I think I see Ada as becoming ubiquitous for cryptography of the intensely critical nature in the encryption of data which is why I posted here.

Not being a hands-on cryptographer in main stream crypto I don't know what amount of formatting is being done in everyday transmissions at present - I envisage a demand for very selective formatting of even mundane regular security in the future however - the user public will demand this as a right - I think the custodians of Ada are the most likely and to my mind the most suitable body to respond to that. Since Ada is the language of the senior government departments of the USA I think there could be a need for refinements by way of formatting even now.

Cheers - Austin

[robin....@gmail.com]

Doesn't PDF do this?

[Denis McMahon]

On Tue, 02 Dec 2014 03:57:04 -0800, Austin Obyrne wrote:

> Latex is a typesetting language that can be encrypted by an Ada program
> and then securely decrypted back to its LaTeX input file format at the
> receiving end.

A competent encryption / decryption system can encrypt and decrypt any
stream of data, which is to say any arbitrarily long sequence of bits, in
other words any file.

The format of the input file should be irrelevant, if the format of the
input file is not irrelevant the first attack vector is that you know
that the decrypted data has a specific format, and you look for clues in
the ciphertext that might relate to the format of the input file.

So, it should not matter whether your plaintext is 7 bit ascii, a
picture, a compressed zip archive of the cia's darkest secrets or Malia
Obamas twitter account, if you run these through a good encryption
algorithm an attacker should be unable to tell, even in possession of the
encryption and decryption algorithms, what the format of the source data
was, or even how long it was (but it's reasonable to deduce it's no
longer than the ciphertext).

You seem convinced that your technique is in some way much more
inherently secure than anything that has gone before. This presumes that
there is some flaw in all that has gone before that you can not only
prove mathematically, but can prove by demonstrating an infallible attack
on the ciphertext to generate the plaintext.

If this is indeed the case, I am sure there are many publications
queueing up to publish your paper demonstrating the fallibility of
currently adopted encryption systems. Perhaps instead of trying to invent
a totally new encryption method, you should concentrate on alerting
people to the flaws in the existing system, and then you could present
your system as the solution to the problem when asked "ok, you've proved
the current algorithms are broken, how do we fix them?"

--
Denis McMahon, denismf...@gmail.com

[johannes falcone]

ok cool

[Peter Chapin]

On Wed, 3 Dec 2014, Denis McMahon wrote:

> So, it should not matter whether your plaintext is 7 bit ascii, a
> picture, a compressed zip archive of the cia's darkest secrets or Malia
> Obamas twitter account, if you run these through a good encryption
> algorithm an attacker should be unable to tell, even in possession of
> the encryption and decryption algorithms, what the format of the source
> data was, or even how long it was (but it's reasonable to deduce it's no
> longer than the ciphertext).

In many applications of cryptography the plaintext is compressed before it
is encrypted so, in fact, it is fairly common for the plaintext to be
longer than the ciphertext.

This is done because the compression "randomizes" the statistics of the
data input to the encryption algorithm and can make the encryption harder
to defeat... even if the attacker knows the compression has occurred and
what compression algorithm was used.

Peter

[gautier...@hotmail.com]

In the triangle {LaTeX, Ada, cryptography} I don't see meaning of the link LaTeX -cryptography, but for the link Ada - LaTeX I take the opportunity of a shameless plug for TeXCAD: http://texcad.sf.net :-)
_________________________
Gautier's Ada programming
http://www.openhub.net/accounts/gautier_bd

[Austin Obyrne]

Hi,

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.

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.

Why Ada + Latex and not C++ and Latex say. Ada is perfect for cryptology - no other language will ever be able to match it (In my view of used Ada and attempting to use C++ - I gave up on the latter).

To me not using latex in tandem with Ada is missing a valuable asset. I believe the Ada industry should look at it - indeed the user public would demand it if they knew the benefits of amalgamating Latex with cryptography and ideally with Ada as the implementing language.

adacrypt

[Pascal Obry]

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

[mrvm...@gmail.com]

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

[Denis McMahon]

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, denismf...@gmail.com

[mrvm...@gmail.com]

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

[Austin Obyrne]

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

[mrvm...@gmail.com]

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

[Simon Wright]

Austin Obyrne <austin...@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
========================================================================

[Austin Obyrne]

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,

[Austin Obyrne]

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

[Shark8]

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;

[Nasser M. Abbasi]

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

[mrvm...@gmail.com]

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

[Austin Obyrne]

On Thursday, December 4, 2014 3:25:46 PM UTC, Simon Wright wrote:

I value your feedback greatly to the extent that I am archiving it as evidence to others - Austin

[Denis McMahon]

On Fri, 05 Dec 2014 00:21:55 -0800, mrvmurray wrote:

> This guy is an intractable crank. He's completely deluded himself with
> his own bullshit.

Every newsgroup seems to contain at least one.

--
Denis McMahon, denismf...@gmail.com

[mrvm...@gmail.com]

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
--