Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

My Ada-95 text book came first day - 10 years ago - with a selection of compilers for Windows, MacOS and Linux.  Having a Windows operating system I automatically installed the Windows compiler from the three and all has gone very well up to now.  That compiler was the gnat 311.p version. My ciphers written in Ada-95 for Microsoft Windows are complete and working very well now after years of work.  I now want to get them to run in Macos and/or Linux also.

It would be naïve to think that they will run in Macos also just by installing that compiler and ditto for Linux – it would be great if they did?.

Before I spend any more money (in short supply) on getting Macos and Linux equipment could anybody who has experience of doing this tell me if the programs written for Windows will run in Macos and/or Linux straight off and if the Windows program source code requires any modification or even if it runs at all.

Your usual help in the past would be greatly appreciated here now.

Adacrypt.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> My Ada-95 text book came first day - 10 years ago - with a selection
> of compilers for Windows, MacOS and Linux.  Having a Windows operating
> system I automatically installed the Windows compiler from the three
> and all has gone very well up to now.  That compiler was the gnat
> 311.p version. My ciphers written in Ada-95 for Microsoft Windows are
> complete and working very well now after years of work.  I now want to
> get them to run in Macos and/or Linux also.
>
> It would be naïve to think that they will run in Macos also just by
> installing that compiler and ditto for Linux – it would be great if
> they did?.
>
> Before I spend any more money (in short supply) on getting Macos and
> Linux equipment could anybody who has experience of doing this tell me
> if the programs written for Windows will run in Macos and/or Linux
> straight off and if the Windows program source code requires any
> modification or even if it runs at all.

I just downloaded your Vector Cipher_2 zip file (and deleted all the .o,
.ali, .exe and b_*.c files!) and, using GNAT GPL 2013 on Mac OS X,
compiled & built real_time_encryption_program_mark_2 with three
warnings:

real_time_encryption_program_mark_2.adb:589:12: warning: unary minus
 expression should be parenthesized here
real_time_encryption_program_mark_2.adb:612:08: warning: unary minus
 expression should be parenthesized here
real_time_encryption_program_mark_2.adb:743:22: warning: "PlainTextNum"
 may be referenced before it has a value

(there were a lot more with -gnatwa, enable all common warnings)

so I think you should be in good shape. Mind you, I didn't run it since
I didn't see any obvious instructions on how to run what look like test
cases.

Before spending any money, why not download the latest GNAT for Windows
from libre.adacore.com and try that? Ada code tends to be very portable.

I'd strongly recommend not bothering with the Linux or Mac compilers
from your textbook; 3.11p is very old, and the Mac version at least
won't even run on recent Macs.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Saturday, December 7, 2013 1:16:05 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > My Ada-95 text book came first day - 10 years ago - with a selection > of compilers for Windows, MacOS and Linux. Having a Windows operating > system I automatically installed the Windows compiler from the three > and all has gone very well up to now. That compiler was the gnat > 311.p version. My ciphers written in Ada-95 for Microsoft Windows are > complete and working very well now after years of work. I now want to > get them to run in Macos and/or Linux also. > > It would be naïve to think that they will run in Macos also just by > installing that compiler and ditto for Linux – it would be great if > they did?. > > Before I spend any more money (in short supply) on getting Macos and > Linux equipment could anybody who has experience of doing this tell me > if the programs written for Windows will run in Macos and/or Linux > straight off and if the Windows program source code requires any > modification or even if it runs at all. I just downloaded your Vector Cipher_2 zip file (and deleted all the .o, .ali, .exe and b_*.c files!) and, using GNAT GPL 2013 on Mac OS X, compiled & built real_time_encryption_program_mark_2 with three warnings: real_time_encryption_program_mark_2.adb:589:12: warning: unary minus expression should be parenthesized here real_time_encryption_program_mark_2.adb:612:08: warning: unary minus expression should be parenthesized here real_time_encr

yption_program_mark_2.adb:743:22: warning: "PlainTextNum" may be referenced before it has a value (there were a lot more with -gnatwa, enable all common warnings) so I think you should be in good shape. Mind you, I didn't run it since I didn't see any obvious instructions on how to run what look like test cases. Before spending any money, why not download the latest GNAT for Windows from libre.adacore.com and try that? Ada code tends to be very portable. I'd strongly recommend not bothering with the Linux or Mac compilers from your textbook; 3.11p is very old, and the Mac version at least won't even run on recent Macs.

Thanks Mark – That is brilliant advice – before I forget it all you need to do is to key in the file names exactly as they appear in the list of test files on screen eg.

PlainTextFile_9.dat
Followed by,
CipherTextFile_9.dat

This will encrypt the first file i.e. the test file called “PlainTextFile_9.dat” into the second one called ‘CipherTextFile_9.dat’

But that is for the Batch Files.

If you then open GENERAL_DECRYPTION_PROGRAM_MARK_2 you will be prompted to enter the ciphertext file for decryption like this,

CipherTextFile_9.dat
Followed by,
MessageTextFile_9.dat

This will decrypt the ciphertext into messagetext – ditto for the other test files before writing your own files – these are just tutorials for anybody who wants them 

May I explain, I am in Ada programming only for one thing – that is to implement three ciphers I have written – I’m problem-solving one problem only and although I like Ada programming at my age it is not worth my while to pursue the finer points of the language.

From what you have told me I think I should leave the dissemination of the finished  ciphers (currently to hand in Ada-95 only but required in all the possible future versions of Ada) to experienced people who are au fait with all the nuances of compilers that are available to day.

The important part for me is getting the basic crypto right.

Huge thanks for your invaluable help and complements of the season to you.

PS – the Real_Time Version Mark_2 is an Email interactive program – there are no  test files but if you follow the prompts it should be OK – in development tests I always call the email file,

“Email_CipherTextFile_X.dat “ 

but you call it what you like making sure to re-enter the same name when you decrypt it in the general decryption program as when doing batch files.


Austin

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Saturday, December 7, 2013 1:16:05 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > My Ada-95 text book came first day - 10 years ago - with a selection > of compilers for Windows, MacOS and Linux. Having a Windows operating > system I automatically installed the Windows compiler from the three > and all has gone very well up to now. That compiler was the gnat > 311.p version. My ciphers written in Ada-95 for Microsoft Windows are > complete and working very well now after years of work. I now want to > get them to run in Macos and/or Linux also. > > It would be naïve to think that they will run in Macos also just by > installing that compiler and ditto for Linux – it would be great if > they did?. > > Before I spend any more money (in short supply) on getting Macos and > Linux equipment could anybody who has experience of doing this tell me > if the programs written for Windows will run in Macos and/or Linux > straight off and if the Windows program source code requires any > modification or even if it runs at all. I just downloaded your Vector Cipher_2 zip file (and deleted all the .o, .ali, .exe and b_*.c files!) and, using GNAT GPL 2013 on Mac OS X, compiled & built real_time_encryption_program_mark_2 with three warnings: real_time_encryption_program_mark_2.adb:589:12: warning: unary minus expression should be parenthesized here real_time_encryption_program_mark_2.adb:612:08: warning: unary minus expression should be parenthesized here real_time_encryption_program_mark_2.adb:743:22: warning: "PlainTextNum" may be referenced before it has a value (there were a lot more with -gnatwa, enable all common warnings) so I think you should be in good shape. Mind you, I didn't run it since I didn't see any obvious instructions on how to run what look like test cases. Before spending any money, why not download the latest GNAT for Windows from libre.adacore.com and try that? Ada code tends to be very portable. I'd strongly recommend not bothering with the Linux or Mac compilers from your textbook; 3.11p is very old, and the Mac version at least won't even run on recent Macs.

Apologies for getting your name wrong (got it mixed up with Mark_2)

Thanks again.

Austin

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> From what you have told me I think I should leave the dissemination of
> the finished ciphers (currently to hand in Ada-95 only but required in
> all the possible future versions of Ada) to experienced people who are
> au fait with all the nuances of compilers that are available to day.

The compilers I've tried with this are Ada2005 natively, and your
programs also work with the -gnat12 (Ada 2012) switch.

You might have tripped over new reserved words, but didn't, and since
you haven't used access or tagged types or tasking I think you'd be
pretty safe to upgrade your compiler.

A couple of points:

(a) when I encrypted

Now is the time for all good men
to come to the aid of the Party.
~

it decrypted as

Now is the time for all good mento come to the aid of the Party.~

Is that meant to happen, or is there a problem with Windows line
terminators (CR/LF) vs Unix (LF)?

(b) when I decrypted Email_CipherTextFile_X.dat I got

Execution terminated by unhandled exception
Exception name: ADA.IO_EXCEPTIONS.DATA_ERROR

and the exception was raised at line 683 of
general_decryption_program_mark_2.adb.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Saturday, December 7, 2013 5:18:06 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > From what you have told me I think I should leave the dissemination of > the finished ciphers (currently to hand in Ada-95 only but required in > all the possible future versions of Ada) to experienced people who are > au fait with all the nuances of compilers that are available to day. The compilers I've tried with this are Ada2005 natively, and your programs also work with the -gnat12 (Ada 2012) switch. You might have tripped over new reserved words, but didn't, and since you haven't used access or tagged types or tasking I think you'd be pretty safe to upgrade your compiler. A couple of points: (a) when I encrypted Now is the time for all good men to come to the aid of the Party. ~ it decrypted as Now is the time for all good mento come to the aid of the Party.~ Is that meant to happen, or is there a problem with Windows line terminators (CR/LF) vs Unix (LF)? (b) when I decrypted Email_CipherTextFile_X.dat I got Execution terminated by unhandled exception Exception name: ADA.IO_EXCEPTIONS.DATA_ERROR and the exception was raised at line 683 of general_decryption_program_mark_2.adb.    

Hi Simon,

The second line down below is line 683

FOR I IN 1 .. 3 LOOP
      *=> Ada.Integer_Text_IO.Get(File => InData, Item => W(I));
      --Ada.Integer_Text_IO.Put(Item => W(I), Width => 8);
END LOOP;
 This appears to be ok to me ?

You are working from a very old edition of this program

Could I ask you to start again and download "SureCrypt Cipher" from 

http://www.adacryptpages.com
 
Sorry for the inconvenience - you are going great guns - the line numbers are difficult for me to trace today in the older program - Note - There is only one of each program in this more recent download.

I think there is always going to be some small errors - ideally I should liaise very closely with anybody such as yourself in any exercises like this.

Can you please spell out exactly which program you are referring to also because I have sometimes renamed them differently over the years in different uploads.

Ada-wise all these programs are the same -just extra refinements have been added now and then.

Thanks for what you are doing.

Austin  

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Saturday, December 7, 2013 5:18:06 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> 
> 
> > From what you have told me I think I should leave the dissemination of
> 
> > the finished ciphers (currently to hand in Ada-95 only but required in
> 
> > all the possible future versions of Ada) to experienced people who are
> 
> > au fait with all the nuances of compilers that are available to day.
> 
> 
> 
> The compilers I've tried with this are Ada2005 natively, and your
> 
> programs also work with the -gnat12 (Ada 2012) switch.
> 
> 
> 
> You might have tripped over new reserved words, but didn't, and since
> 
> you haven't used access or tagged types or tasking I think you'd be
> 
> pretty safe to upgrade your compiler.
> 
> 
> 
> A couple of points:
> 
> 
> 
> (a) when I encrypted
> 
> 
> 
> Now is the time for all good men
> 
> to come to the aid of the Party.
> 
> ~
> 
> 
> 
> it decrypted as
> 
> 
> 
> Now is the time for all good mento come to the aid of the Party.~
> 
> 
> 
> Is that meant to happen, or is there a problem with Windows line
> 
> terminators (CR/LF) vs Unix (LF)?
> 
> 
> 
> (b) when I decrypted Email_CipherTextFile_X.dat I got
> 
> 
> 
> Execution terminated by unhandled exception
> 
> Exception name: ADA.IO_EXCEPTIONS.DATA_ERROR
> 
> 
> 
> and the exception was raised at line 683 of
> 
> general_decryption_program_mark_2.adb.

Hi Simon, 

"The compilers I've tried with this are Ada2005 natively, and your 
programs also work with the -gnat12 (Ada 2012) switch."

This answers the general question will the software run in Macos ?.

You have done me proud with your researches and I am hugely grateful.

Many thanks for everything.

Austin

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> Could I ask you to start again and download "SureCrypt Cipher" from 
>
> http://www.adacryptpages.com

Things are not as good as I'd hoped.

The programs build OK (aside from a warning or two), but
general_decryption_program_mark_1 fails immediately with

   Execution terminated by unhandled exception
   Exception name: STORAGE_ERROR
   Message: stack overflow

at the start of the main program. This is usually a symptom of not
having enough stack space, caused (in your case) by having lots of large
arrays in the main program, not helped by initialising them - there was
a recent thread[1] here about this.

On the Mac there's a default stack limit of 8Mb; other OS's will have
different limits, if limits at all.

After poking at this for some time, there are two solutions:

(a) move all the array declarations to a package of their own (for
example, General_Decryption_Program_Mark_1_Arrays) and with/use it. The
arrays are no longer on the stack (I'm not sure about the initializers).

(b) increase the program's stack size. The help for gnatbind says I
could add the switch -d16m for a 16 Mb stack, but this had no effect;
instead, there's a Mac-specific way of doing this which I won't bore you
with.


Having got the program to start, I tried to decrypt the supplied
CipherTextFile_1.dat and got

   Execution terminated by unhandled exception
   Exception name: ADA.IO_EXCEPTIONS.DATA_ERROR

and as far as I can tell this was caused by the Windows line
terminator[2] in the data file; that's to say, when I removed the CR
character from the Windows CR/LF the program decoded correctly.

I'm not sure of the best way to get an Ada program not to care what sort
of input line terminators it's reading.

--S

[1]
https://groups.google.com/forum/?hl=en#!searchin/comp.lang.ada/large$20array%7Csort:date/comp.lang.ada/d-HSSQR9jHo/NjNp6cl6WaIJ
[2] http://en.wikipedia.org/wiki/Newline

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Jeffrey Carter]

On 12/08/2013 10:17 AM, Simon Wright wrote:
>
> I'm not sure of the best way to get an Ada program not to care what sort
> of input line terminators it's reading.

You read the file using something like Sequential_IO and handle line terminators 
yourself.

I found that on Linux one can handle Windows line terminators by using Text_IO 
and checking if the last character is a CR. However, files in "Mac format" (CR 
for line terminator) don't work with Text_IO under Linux.

-- 
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus
53

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Sunday, December 8, 2013 5:17:45 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > Could I ask you to start again and download "SureCrypt Cipher" from > > http://www.adacryptpages.com Things are not as good as I'd hoped. The programs build OK (aside from a warning or two), but general_decryption_program_mark_1 fails immediately with Execution terminated by unhandled exception Exception name: STORAGE_ERROR Message: stack overflow at the start of the main program. This is usually a symptom of not having enough stack space, caused (in your case) by having lots of large arrays in the main program, not helped by initialising them - there was a recent thread[1] here about this. On the Mac there's a default stack limit of 8Mb; other OS's will have different limits, if limits at all. After poking at this for some time, there are two solutions: (a) move all the array declarations to a package of their own (for example, General_Decryption_Program_Mark_1_Arrays) and with/use it. The arrays are no longer on the stack (I'm not sure about the initializers). (b) increase the program's stack size. The help for gnatbind says I could add the switch -d16m for a 16 Mb stack, but this had no effect; instead, there's a Mac-specific way of doing this which I won't bore you with. Having got the program to start, I tried to decrypt the supplied CipherTextFile_1.dat and got Execution terminated by unhandled exception Exception name: ADA.IO_EXCEPTIONS.DATA_ERROR and as far as I can tell this was caused by the Windows line terminator[2] in the data file; that's to say, when I removed the CR character from the Windows CR/LF the program decoded correctly. I'm not sure of the best way to get an Ada program not to care what sort of input line terminators it's reading. --S [1] https://groups.google.com/forum/?hl=en#!searchin/comp.lang.ada/large$20array%7Csort:date/comp.lang.ada/d-HSSQR9jHo/NjNp6cl6WaIJ [2] http://en.wikipedia.org/wiki/Newline

Hi Simon,

I think part of the trouble may be caused by one very large counting array that is not really necessary to the running of the program in the program as follows,

Could I ask you to comment out all of this counting function and try again.

GENERAL_DECRYPTION_PROGRAM_MARK_1.adb

This is the array in question – note I have commented it out later.

SUBTYPE Index_34 IS Integer RANGE -1000000 .. 1000000;
TYPE I_CoefficientsNumArray IS ARRAY(Index_34) OF Integer;
I_Num : I_CoefficientsNumArray:= (others =>0);
  -- counts the nominated coefficients of the ciphertext.
 
*Could I ask you to totally disable this counting function by commenting out these lines of source code as follows.
 
Line 32      --    Q    : Integer;

Lines 238, 239, 240. 241 

--  SUBTYPE Index_34 IS Integer RANGE -1000000 .. 1000000;
--  TYPE I_CoefficientsNumArray IS ARRAY(Index_34) OF Integer;
--  I_Num : I_CoefficientsNumArray:= (others =>0);
--  -- counts the nominated coefficients of the ciphertext.

Lines 881, 882,

--  Q:= W(1)REM 1000000;
--  I_Num(Q) := I_Num(Q)+1;

Pleases see next,

BATCH_ENCRYPTION_PROGRAM_MARK_1.adb

The corresponding lines to be commented out in the encryption program are,

Line 32: --    Q    : Integer;

Lines 251,252,253,254

--  SUBTYPE Index_36 IS Integer RANGE -1000000 .. 1000000;
--  TYPE I_CoefficientsNumArray IS ARRAY(Index_36) OF Integer;
--  I_Num : I_CoefficientsNumArray:= (others =>0);
--  -- counts the nominated coefficients of the ciphertext.

Lines 972,973

--  Q:= W(1)REM 1000000;
--  I_Num(Q) := I_Num(Q)+1;
 
Finally, 

EMAIL_ENCRYPTIONS_MARK_1.adb

The lines for commenting out here are,

Line 33: --    Q    : Integer;
253,254,255,256,

--  SUBTYPE Index_36 IS Integer RANGE -1000000 .. 1000000;
--  TYPE I_CoefficientsNumArray IS ARRAY(Index_36) OF Integer;
--  I_Num : I_CoefficientsNumArray:= (others =>0);
--  -- counts the nominated coefficients of the ciphertext.

Lines 940,941,

--  Q:= W(1)REM 1000000;
--  I_Num(Q) := I_Num(Q)+1;

• I have test run the programs after this commenting out exercise and they run ok.

Thanks for going to this extreme trouble.

I think the line problem requires an exception handler related to the GET function.(fools ruch in....)

Austin.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> However, files in "Mac format" (CR for line terminator) don't work
> with Text_IO under Linux.

That's a very old 'Mac format', of course. Unix-style nowadays.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> (b) increase the program's stack size. The help for gnatbind says I
> could add the switch -d16m for a 16 Mb stack, but this had no effect;
> instead, there's a Mac-specific way of doing this which I won't bore
> you with.

See http://forward-in-code.blogspot.co.uk/2013/12/controlling-executables-stack-size.html

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Stephen Leake]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> It would be naïve to think that they will run in Macos also just by
> installing that compiler and ditto for Linux – 

If they don't do GUI stuff, or rely on the details of the file system,
it's not naive.

-- 
-- Stephe

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> I think part of the trouble may be caused by one very large counting
> array that is not really necessary to the running of the program in
> the program as follows,
>
> Could I ask you to comment out all of this counting function and try
> again.

I did this in general_decryption_program_mark_1.adb and it now starts
running OK.

I didn't check the others but I would expect this change to work for
them too.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Sunday, December 8, 2013 8:10:27 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > I think part of the trouble may be caused by one very large counting > array that is not really necessary to the running of the program in > the program as follows, > > Could I ask you to comment out all of this counting function and try > again. I did this in general_decryption_program_mark_1.adb and it now starts running OK. I didn't check the others but I would expect this change to work for them too.

Digressing completely from 'vector' cryptography can I suggest experimenting with the "Scalable Key Cipher" until you get the line terminators sorted and then come back to vector crypto later.

Having three coefficients in vector cryptography can complicate things (I think)

Can I ask you to consider downloading, "Scalable Key Cipher" from 

http:www.adacryptpages.com 

and trying that as a precursor to the the more complicated "SureCrypt" algorithm later on.

"Scalable Key" is scalar crypto - the ciphertext is a string of integers also but only one to each plaintext being encrypted instead of three as in Vector Crypto.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Jeffrey Carter]

On 12/08/2013 01:00 PM, Simon Wright wrote:
> Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
>
>> However, files in "Mac format" (CR for line terminator) don't work
>> with Text_IO under Linux.
>
> That's a very old 'Mac format', of course. Unix-style nowadays.

Yes, certainly, but I encountered it in the last couple of years. It was a file 
output by Excel, IIRC, and the user had specified "Mac format" by accident. To 
the Get_Line function it looked like a single, 5M-character string.

-- 
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus
53

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Sunday, December 8, 2013 8:10:27 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > I think part of the trouble may be caused by one very large counting > array that is not really necessary to the running of the program in > the program as follows, > > Could I ask you to comment out all of this counting function and try > again. I did this in general_decryption_program_mark_1.adb and it now starts running OK. I didn't check the others but I would expect this change to work for them too.

The test files and general layout is identical in scalar “Scalable Key Cipher” to "SureCrypt" vector cipher.  I think the three coefficients of vector crypto are giving problems that will be better understood after running scalable key.

I suggest you change over to this for the present unless of course things pan out OK when you run the other.

The transition of this crypto from Windows to Mac is quite something and to my limited experience is a formidable task.

It will be invaluable experience to everybody if you can iron out the differences.

Austin

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lywqjf45za.fsf@pushface.org...
...
> and as far as I can tell this was caused by the Windows line
> terminator[2] in the data file; that's to say, when I removed the CR
> character from the Windows CR/LF the program decoded correctly.
>
> I'm not sure of the best way to get an Ada program not to care what sort
> of input line terminators it's reading.

I'm surprised that that would be a problem, at least for Unix and Windows 
files. It's pretty simple to design Text_IO so that it can read either 
properly; that's how Text_IO in Janus/Ada works. (The only difference for it 
between Windows and Unix versions is the characters output by New_Line). Of 
course, such a Text_IO would make a real hash out of old Mac files. (I 
usually use an Ada program to convert text files to Windows format; it's 
just a simple loop of Get_Line/Put_Line pairs.)

But if you don't want to change the terminators (or your compiler has an 
unnecessarily inflexible Text_IO), I'd suggest using Stream_IO. Of course, 
then you'll have to do your own buffering of input (but that's usually a 
good idea anyway).

                                       Randy.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Tuesday, December 10, 2013 6:37:28 AM UTC, Randy Brukardt wrote:
> "Simon Wright" <simon@pushface.org> wrote in message news:lywqjf45za.fsf@pushface.org... ... > and as far as I can tell this was caused by the Windows line > terminator[2] in the data file; that's to say, when I removed the CR > character from the Windows CR/LF the program decoded correctly. > > I'm not sure of the best way to get an Ada program not to care what sort > of input line terminators it's reading. I'm surprised that that would be a problem, at least for Unix and Windows files. It's pretty simple to design Text_IO so that it can read either properly; that's how Text_IO in Janus/Ada works. (The only difference for it between Windows and Unix versions is the characters output by New_Line). Of course, such a Text_IO would make a real hash out of old Mac files. (I usually use an Ada program to convert text files to Windows format; it's just a simple loop of Get_Line/Put_Line pairs.) But if you don't want to change the terminators (or your compiler has an unnecessarily inflexible Text_IO), I'd suggest using Stream_IO. Of course, then you'll have to do your own buffering of input (but that's usually a good idea anyway). Randy.

Can I have a very small say here while you heavyweights give your more experienced suggestions.

My Ada program in its present form which I am very loth to change must always use the 'GET' and 'PUT' functions and the attributes  'Pos and 'Val for handling the incomming plaintext and the the outgoing ciphertext.

This is the highly salient property that enables vast tracts of data to be read in automatically in one fell swoop by the cipher (even the source code that Ada programs use) without human intervention (certainly not requiring hand-picked graduates as at present).  

Future usage of encryption to secure files will benefit hugely from this becuse it can be done by any lay person on a home computer who needs no knowledge of programmimg, cryptography or mathematics and just two-finger keyboarding is sufficient.

Can I say thanks to all of you who are subscribing to this discussion - thus far I have been assured that my stuff will run in gnat 2013 on MAC - that is just great - I would dearly like to know also if any reader is totally on top of it all and is able to run the test programs. encrypt their own batch files , send encrypted emails and do external blanket encrytion of old files for back up and secure archiving etc. 

adacrypt

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Tuesday, December 10, 2013 6:37:28 AM UTC, Randy Brukardt wrote:
> "Simon Wright" <simon@pushface.org> wrote in message news:lywqjf45za.fsf@pushface.org... ... > and as far as I can tell this was caused by the Windows line > terminator[2] in the data file; that's to say, when I removed the CR > character from the Windows CR/LF the program decoded correctly. > > I'm not sure of the best way to get an Ada program not to care what sort > of input line terminators it's reading. I'm surprised that that would be a problem, at least for Unix and Windows files. It's pretty simple to design Text_IO so that it can read either properly; that's how Text_IO in Janus/Ada works. (The only difference for it between Windows and Unix versions is the characters output by New_Line). Of course, such a Text_IO would make a real hash out of old Mac files. (I usually use an Ada program to convert text files to Windows format; it's just a simple loop of Get_Line/Put_Line pairs.) But if you don't want to change the terminators (or your compiler has an unnecessarily inflexible Text_IO), I'd suggest using Stream_IO. Of course, then you'll have to do your own buffering of input (but that's usually a good idea anyway). Randy.

Hi Randy,

May I chip in with this layman’s suggestion however daft it may seem to you guys (all my Ada has been learned by teasing out mechanical models that I invented and conjecture as being Ada syntax errors eliminating them one by one until it is compiled and built ok).  

*I am in Ada just for one solitary piece of problem solving i.e. the implementation of my ciphers in a programming language that I like so here goes.
I don't anything about what's under the bonnet of the Ada Rolls Royce.

Please consider this procedure in the program that gave trouble,

This is the defacto stripped down procedure

EXIT when EOF;
  EXIT when EOL;

    FOR I IN 1 .. 3 LOOP
      Ada.Integer_Text_IO.Get(File => InData, Item => W(I));
      --Ada.Integer_Text_IO.Put(Item => W(I), Width => 8);
    END LOOP;

LOOP;
LOOP;

The EOF marker on my computer is the right arrow => (element number 26 in Latin-1)

I don’t know what EOL is (yet)

Could it be that the 'FOR' loop is somehow getting out of sync with EOL ???? i.e. not being completed at the computer-perceived EOL ???

Fools rush in …..

Regards 

Austin - adacrypt

 

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Randy Brukardt]

"Austin Obyrne" <austin.obyrne@hotmail.com> wrote in message 
news:2b6dc37f-4aa6-4c18-be59-8c09f6f37f01@googlegroups.com...
On Tuesday, December 10, 2013 6:37:28 AM UTC, Randy Brukardt wrote:
...
>Please consider this procedure in the program that gave trouble,
>
>This is the defacto stripped down procedure
>
>EXIT when EOF;
>  EXIT when EOL;
>
>    FOR I IN 1 .. 3 LOOP
>      Ada.Integer_Text_IO.Get(File => InData, Item => W(I));
>      --Ada.Integer_Text_IO.Put(Item => W(I), Width => 8);
>    END LOOP;
>
>LOOP;
>LOOP;

I presume that there is a New_Line in there somewhere so that the line 
endings aren't lost completely.

But this isn't going to work, as Get for a character is defined as follows: 
"After skipping any line terminators and any page terminators, reads the 
next character from the specified input file and returns the value of this 
character in the out parameter Item."

So if you have any line endings in between the 1st and 2nd characters (or 
between the 2nd and 3rd characters), you'll end up ignoring them. I doubt 
that's what you want. (Ada abstracts the line, page, and file terminators so 
you don't have to worry about how they're represented. The problem being 
that you *can't* see how they're represented if you are using Text_IO.)

Using Text_IO without losing line endings and the like is tricky. I 
generally don't bother, just reading a line at a time with Get_Line and then 
process whatever I get. (And I just ignore page terminators, which are 
rarely used anyway.)

But if I was writing this sort of code, I wouldn't worry about line endings 
at all, and simply encrypt the file as binary data, using Stream_IO to read 
it in and out.

                                    Randy.

Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Clubley]

On 2013-12-10, Randy Brukardt <randy@rrsoftware.com> wrote:
>
> But if I was writing this sort of code, I wouldn't worry about line endings 
> at all, and simply encrypt the file as binary data, using Stream_IO to read 
> it in and out.
>

Thank you. That's one of a number of things I don't understand about this.

A serious encryption tool is going to treat the input as a opaque stream of
bytes not as text.

I don't encrypt pure text, but I _do_ encrypt full directory trees which
may have a mixture of text and binary files within them.

I don't understand how someone who claims to have invented something new
cannot realise this.

And to the OP: while I can certainly understand the desire to remain
with Ada 95, what I don't understand is why you insist on using such a
specific version from a range of long obsolete compiler versions.

Can you explain your reasoning ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lywqjf45za.fsf@pushface.org...
> ...
>> I'm not sure of the best way to get an Ada program not to care what
>> sort of input line terminators it's reading.
>
> I'm surprised that that would be a problem, at least for Unix and
> Windows files. It's pretty simple to design Text_IO so that it can
> read either properly; that's how Text_IO in Janus/Ada works. (The only
> difference for it between Windows and Unix versions is the characters
> output by New_Line).

GNAT is certainly not as clever as that. On Mac OS X, this program

========================================================================
with Ada.Streams.Stream_IO;
with Ada.Integer_Text_IO;
with Ada.Text_IO; use Ada.Text_IO;

procedure S is

   Data_File_Name : constant String := "s.dat";
   Text_File : Ada.Text_IO.File_Type;

   procedure Write_As_Stream (Data : String) is
      package ASS renames Ada.Streams.Stream_IO;
      Stream_File : ASS.File_Type;
   begin
      ASS.Open (Stream_File,
                Name => Data_File_Name,
                Mode => ASS.Out_File);
      declare
         Stream_Access : constant ASS.Stream_Access
           := ASS.Stream (Stream_File); -- the file has to be open already
      begin
         String'Write (Stream_Access, Data);
      end;
      ASS.Close (Stream_File);
   end Write_As_Stream;

begin

   Put_Line ("testing \n");
   Write_As_Stream (String'(1 => ASCII.LF));
   Open (Text_File, Name => Data_File_Name, Mode => In_File);
   Put_Line ("EOL is " & Boolean'Image (End_Of_Line (Text_File)));
   Put_Line ("EOF is " & Boolean'Image (End_Of_File (Text_File)));
   Close (Text_File);

   Put_Line ("testing \r\n");
   Write_As_Stream (String'(1 => ASCII.CR, 2 => ASCII.LF));
   Open (Text_File, Name => Data_File_Name, Mode => In_File);
   Put_Line ("EOL is " & Boolean'Image (End_Of_Line (Text_File)));
   Put_Line ("EOF is " & Boolean'Image (End_Of_File (Text_File)));
   Close (Text_File);

   declare
      Dummy : Integer;
   begin
      Put_Line ("testing \n42");
      Write_As_Stream (String'(1 => ASCII.LF) & "42");
      Open (Text_File, Name => Data_File_Name, Mode => In_File);
      Ada.Integer_Text_IO.Get (Text_File, Dummy);
      Put_Line ("Value is " & Integer'Image (Dummy));
      Close (Text_File);
   end;

   declare
      Dummy : Integer;
   begin
      Put_Line ("testing \r\n42");
      Write_As_Stream (String'(1 => ASCII.CR, 2 => ASCII.LF) & "42");
      Open (Text_File, Name => Data_File_Name, Mode => In_File);
      Ada.Integer_Text_IO.Get (Text_File, Dummy);
      Put_Line ("Value is " & Integer'Image (Dummy));
      Close (Text_File);
   end;

end S;
========================================================================

results in

------------------------------------------------------------------------
testing \n
EOL is TRUE
EOF is TRUE
testing \r\n
EOL is FALSE
EOF is FALSE
testing \n42
Value is  42
testing \r\n42

Execution terminated by unhandled exception
Exception name: ADA.IO_EXCEPTIONS.DATA_ERROR
------------------------------------------------------------------------

whereas on a Windows machine I get

------------------------------------------------------------------------
testing \n
EOL is TRUE
EOF is TRUE
testing \r\n
EOL is TRUE
EOF is TRUE
testing \n42
Value is  42
testing \r\n42
Value is  42
------------------------------------------------------------------------

so I feel a bug report coming on .. 

> But if you don't want to change the terminators (or your compiler has an 
> unnecessarily inflexible Text_IO), I'd suggest using Stream_IO. Of course, 
> then you'll have to do your own buffering of input (but that's usually a 
> good idea anyway).

Yes. Actually I tried Sequential_IO, but for just reading Characters
there's not a lot of difference ... is there?

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Jeffrey Carter]

On 12/10/2013 05:34 PM, Simon Wright wrote:
>
> results in
>
> ------------------------------------------------------------------------
> testing \n
> EOL is TRUE
> EOF is TRUE
> testing \r\n
> EOL is FALSE
> EOF is FALSE
> testing \n42
> Value is  42
> testing \r\n42
>
> Execution terminated by unhandled exception
> Exception name: ADA.IO_EXCEPTIONS.DATA_ERROR

On Linux (GNAT 4.6), it results in

$ ./s
testing \n

raised ADA.IO_EXCEPTIONS.NAME_ERROR : s.dat: No such file or directory

and indeed s.dat does not exist.

If I change the Open to Create in Write_As_Stream, I get

$ ./s
testing \n
EOL is TRUE
EOF is TRUE
testing \r\n
EOL is FALSE
EOF is FALSE
testing \n42
Value is  42
testing \r\n42

raised ADA.IO_EXCEPTIONS.DATA_ERROR : a-tiinio.adb:66 instantiated at 
a-inteio.ads:18

-- 
Jeff Carter
"I've got to stay here, but there's no reason
why you folks shouldn't go out into the lobby
until this thing blows over."
Horse Feathers
50

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Dmitry A. Kazakov]

On Tue, 10 Dec 2013 23:08:40 +0000 (UTC), Simon Clubley wrote:

> On 2013-12-10, Randy Brukardt <randy@rrsoftware.com> wrote:
>>
>> But if I was writing this sort of code, I wouldn't worry about line endings 
>> at all, and simply encrypt the file as binary data, using Stream_IO to read 
>> it in and out.
> 
> Thank you. That's one of a number of things I don't understand about this.
> 
> A serious encryption tool is going to treat the input as a opaque stream of
> bytes not as text.

That depends. I remember porting early versions of PGP to SysV and VMS,
back in early 90's. It was all about text files which must have been
converted, recoded etc in order to be readable.

> I don't encrypt pure text, but I _do_ encrypt full directory trees which
> may have a mixture of text and binary files within them.

No difference. Extrapolating your logic, there is no tree and no files just
a chunk of disk image. Directory tree is no better abstraction than lines
of a text file. It works so long all targets share the abstraction. For
either directory trees or text files that does not hold.

Having said that, I strongly believe that whatever encryption, it should be
done on the transport layer and never on the application layer. So in the
end I agree with you, but not with your argument.
 
> I don't understand how someone who claims to have invented something new
> cannot realise this.

Yes, Op's postings leave a quite strange impression.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> $ ./s
> testing \n
>
> raised ADA.IO_EXCEPTIONS.NAME_ERROR : s.dat: No such file or directory
>
> and indeed s.dat does not exist.

Drat.

I forgot to add that you need to do (the equivalent of) "touch s.dat"
before running the program (I thought it was quite long enough already
without adding the Create/Open dance).

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>>              It's pretty simple to design Text_IO so that it can
>> read either properly; that's how Text_IO in Janus/Ada works. (The only
>> difference for it between Windows and Unix versions is the characters
>> output by New_Line).
>
> GNAT is certainly not as clever as that. On Mac OS X, this program
[...]
> so I feel a bug report coming on .. 

Actually, GNAT goes half way[1]: Unix files are supported on Windows,
but Windows files aren't supported on Unix.

So it'll be an enhancement request.

[1] http://gcc.gnu.org/onlinedocs/gnat_rm/Text-Translation.html

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Tuesday, December 10, 2013 9:49:36 PM UTC, Randy Brukardt wrote: > "Austin Obyrne" <austin.obyrne@hotmail.com> wrote in message news:2b6dc37f-4aa6-4c18-be59-8c09f6f37f01@googlegroups.com... On Tuesday, December 10, 2013 6:37:28 AM UTC, Randy Brukardt wrote: ... >Please consider this procedure in the program that gave trouble, > >This is the defacto stripped down procedure > >EXIT when EOF; > EXIT when EOL; > > FOR I IN 1 .. 3 LOOP > Ada.Integer_Text_IO.Get(File => InData, Item => W(I)); > --Ada.Integer_Text_IO.Put(Item => W(I), Width => 8); > END LOOP; > >LOOP; >LOOP; I presume that there is a New_Line in there somewhere so that the line endings aren't lost completely. But this isn't going to work, as Get for a character is defined as follows: "After skipping any line terminators and any page terminators, reads the next character from the specified input file and returns the value of this character in the out parameter Item." So if you have any line endings in between the 1st and 2nd characters (or between the 2nd and 3rd characters), you'll end up ignoring them. I doubt that's what you want. (Ada abstracts the line, page, and file terminators so you don't have to worry about how they're represented. The problem being that you *can't* see how they're represented if you are using Text_IO.) Using Text_IO without losing line endings and the like is tricky. I generally don't bother, just reading a line at a time with Get_Line and then process whatever I get. (And I just ignore page terminators, which are rarely used anyway.) But if I was writing this sort of code, I wouldn't worry about line endings at all, and simply encrypt the file as binary data, using Stream_IO to read it in and out. Randy.

 Hi Randy, I am not in that league of theoretical Ada that I can debate with any of you guys. For your info there are lots of New_Lines in the sample I submitted but I think there are other instances where there may be only one. My Ada programs have NEVER failed in thousands of runs - in fact they have never failed for any language syntax reason in about 10 years!. I am taking on board what you say is a definition of GET for pondering later. Can I tell you where I am coming from, Forget about programming my ciphers in the Ada language or any language. The cryptographic strength of the cipher depends on the veracity of the mathematical proof of the cipher algorithm alone. That in my case is written in stone. Demonstrating the cipher in Ada is the language I happen to greatly favour because of the workmanlike transparency of this langauge but the fact of my using gnat 311.p is merely a token and other updated gnat evrsions will always need to tested like right now 2013 version of MAC. Fundamentally, the crypto strength is both insured and assured beforehand regardless of how it runs in programs and if it fails for programmimg language reasons that is something that can be fixed and it is not as serious as being broken by cryptanalysis. 


I am of the belief there are always going to be problems to be expected when changing platforms like this. Up to now the programs to hand are very, very solid and even surprise me at the things they seem to shake off like encrypting source code so accurately where the smallest lack of fidelity could cause it to not run later on the decrypted sourcecode. I think that in the future each implementation on whatever platform is going to need tweaking initially but once that is done the natural stability of Ada will take over thereafter and when the cipher is wrtten it is there for all time. 

*It is hugely important for me to establish the fact that the cryptographic strength of my ciphers is ring-fenced independently of any langauge and may even be done in longhand fashion of push came to shove.

The class of these ciphers is demonstrably the ultimate clas of "Theoretically Unbreakable" and must not be undermined ever by whatever language is used - that is merely a conveyance - achieving cryptographic of perfect secercy is so difficult it is almost like a Greek Classic.

adacrypt.

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Tuesday, December 10, 2013 11:08:40 PM UTC, Simon Clubley wrote:
> On 2013-12-10, Randy Brukardt <randy@rrsoftware.com> wrote: > > But if I was writing this sort of code, I wouldn't worry about line endings > at all, and simply encrypt the file as binary data, using Stream_IO to read > it in and out. > Thank you. That's one of a number of things I don't understand about this. A serious encryption tool is going to treat the input as a opaque stream of bytes not as text. I don't encrypt pure text, but I _do_ encrypt full directory trees which may have a mixture of text and binary files within them. I don't understand how someone who claims to have invented something new cannot realise this. And to the OP: while I can certainly understand the desire to remain with Ada 95, 


<what I don't understand is why you insist on using such a specific version <from a range of long obsolete compiler versions. Can you explain your <reasoning ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-<Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world

Hi Simon,

The gnat 311.p compiler happens to be the one that I use to develop my cipher program source code in my three ciphers over 10 years ago.  

There is nothing binding about a compiler – if it works leave it alone unless you can benefit from the attributes of revised versions in 2013 there is no point in trying to improve on what you’ve got - each download, sale or whatever of my software comes with a gnat 311.p compiler provided ready for installing at the click of a mouse and is certain to work  – in passing this compiler loads like a treat in Windows XP, Vista, 7,& 8.  

There is nothing decadent about using an older compiler.  This compiler works even better than recent updated (revised) versions of the Ada language so there is no criticism that can be made on the back of being an older version.  There is no benefit whatever in using more recent compilers and as you can see it even leads to the trouble being discussed here.

It is not anachronistic to use an old compiler.  

•The ‘C’ language is still being used to write important components of systems and see how old that is.

Compilers in my understanding are updated solely so as to incorporate better ways of doing known criteria or of introducing totally fresh methods but if you don’t need these why change from what you’ve got?

The only downside of my scheme of disseminating my software with the same copied compiler in every case is that the compiler number is the same every time but is that an exploitable defect – No way do think so!

I hope this answers your question.

Austin

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Clubley]

On 2013-12-11, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 10 Dec 2013 23:08:40 +0000 (UTC), Simon Clubley wrote:
>
>> On 2013-12-10, Randy Brukardt <randy@rrsoftware.com> wrote:
>>>
>>> But if I was writing this sort of code, I wouldn't worry about line endings 
>>> at all, and simply encrypt the file as binary data, using Stream_IO to read 
>>> it in and out.
>> 
>> Thank you. That's one of a number of things I don't understand about this.
>> 
>> A serious encryption tool is going to treat the input as a opaque stream of
>> bytes not as text.
>
> That depends. I remember porting early versions of PGP to SysV and VMS,
> back in early 90's. It was all about text files which must have been
> converted, recoded etc in order to be readable.
>
>> I don't encrypt pure text, but I _do_ encrypt full directory trees which
>> may have a mixture of text and binary files within them.
>
> No difference. Extrapolating your logic, there is no tree and no files just
> a chunk of disk image.

And as far as the encryption layer is concerned that's absolutely correct.

> Directory tree is no better abstraction than lines
> of a text file. It works so long all targets share the abstraction. For
> either directory trees or text files that does not hold.
>

Actually, it does hold for directory trees when you consider the abstraction
level at which the encryption is typically applied.

I have two typical usage cases when it comes to encryption.

1) I tar up a directory into a tar archive and then pass the tar file through
gpg. As far as gpg is concerned, the tar archive is just a opaque binary
blob. When decrypting the archive, the opaque binary data is output by
gpg into tar and it's tar, a higher level part of the process, which
assigns meaning to the encrypted data.

2) I use LUKS for full disk (or more accurately, full partition) encryption.
In this case the ext2 filesystem layer is above the encryption layer so
once again, all the encryption layer is interested in is encrypting a series
of opaque data blocks.

It's the upper ext2 filesystem layer which assigns meaning to the decrypted
opaque (as seen by the encryption layer) data blocks; the encryption layer
should not care about what it is encrypting.

There may be some minor usage cases for doing text conversion within the
encryption tool, but it's not the typical usage case, especially these
days.

> Having said that, I strongly believe that whatever encryption, it should be
> done on the transport layer and never on the application layer. So in the
> end I agree with you, but not with your argument.
>  

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Dmitry A. Kazakov]

On Wed, 11 Dec 2013 12:50:45 +0000 (UTC), Simon Clubley wrote:

> I have two typical usage cases when it comes to encryption.
> 
> 1) I tar up a directory into a tar archive and then pass the tar file through
> gpg. As far as gpg is concerned, the tar archive is just a opaque binary
> blob. When decrypting the archive, the opaque binary data is output by
> gpg into tar and it's tar, a higher level part of the process, which
> assigns meaning to the encrypted data.

You assume tar available on the other end and that tar would recode stuff.
As an example consider RSX-11M as a target. Your tar (if you find one
there) would have to translate file paths into something like
DK:[1,54]FOO.TXT (limited to RADIX-50 code set) and file bodies into
FILES-11 records.

> 2) I use LUKS for full disk (or more accurately, full partition) encryption.
> In this case the ext2 filesystem layer is above the encryption layer so
> once again, all the encryption layer is interested in is encrypting a series
> of opaque data blocks.

Yes, this is a reasonable approach as opposed to #1. In effect you have a
virtual file system on both ends above the encryption layer. #1 is rather
encryption above the file system.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> You assume tar available on the other end and that tar would recode
> stuff.  As an example consider RSX-11M as a target. Your tar (if you
> find one there) would have to translate file paths into something like
> DK:[1,54]FOO.TXT (limited to RADIX-50 code set) and file bodies into
> FILES-11 records.

I'm glad I've never had to do that.

But if it's possible to transfer the files at all it should be possible
still to encrypt the transport layer.

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[G.B.]

On 11.12.13 09:35, Dmitry A. Kazakov wrote:
> On Tue, 10 Dec 2013 23:08:40 +0000 (UTC), Simon Clubley wrote:
>
>> On 2013-12-10, Randy Brukardt <randy@rrsoftware.com> wrote:
>>>
>>> But if I was writing this sort of code, I wouldn't worry about line endings
>>> at all, and simply encrypt the file as binary data, using Stream_IO to read
>>> it in and out.
>>
>> Thank you. That's one of a number of things I don't understand about this.
>>
>> A serious encryption tool is going to treat the input as a opaque stream of
>> bytes not as text.

I'd think encryption will be processing a stream of bits, no?

What's a byte and why or how should the dissection of the stream
into bytes be fine whereas a textual representation should not?
Units of 2**(n*8) may be a good choice for some algorithms written
for n*8-bit hardware, if it's not using signs.

Anyway, a serious attempt at encryption requires, I guess, a SINA box
or some such.

> That depends. I remember porting early versions of PGP to SysV and VMS,
> back in early 90's. It was all about text files which must have been
> converted, recoded etc in order to be readable.

Indeed, pieces of data and pieces of text are isomorphic,
e.g. by way of

    Base64 : Bits -> Text.

The issue if binary vs text thus seems one of practicality, not
one of encryption?

Text is sometimes seen as more robust in the presence of old
software that has char caused MSB problems. So, given PGP has ascii
armored coding, in support of stone aged transport layers, why not
just require that encryption start at 7bit data units?
(This restriction helps keeping faulty produces in place, and it
allows continuing the ASCII caused destruction of well educated text
processing. ;-)

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Eryndlia Mavourneen]

On Wednesday, December 11, 2013 8:53:58 AM UTC-6, G.B. wrote:
> why not
> just require that encryption start at 7bit data units?
> (This restriction helps keeping faulty produces in place, and it
> allows continuing the ASCII caused destruction of well educated text
> processing. ;-)

I think your are joking, since your post does not seem to indicate what you would do with the 8th bit of every byte, assuming your input is 8-bit bytes.  Of course, 7-bit ASCII would be unusable when dealing with videos, j-pegs, even Word documents.  What is the problem with simply reading binary disk blocks as 8-bit text using Sequential_IO, since Austin wants to use the attributes 'Pos and 'Val on the data stream?

-- Eryndlia Mavourneen (KK1T)

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Wednesday, December 11, 2013 3:14:37 PM UTC, Eryndlia Mavourneen wrote:
> On Wednesday, December 11, 2013 8:53:58 AM UTC-6, G.B. wrote: > why not > just require that encryption start at 7bit data units? > (This restriction helps keeping faulty produces in place, and it > allows continuing the ASCII caused destruction of well educated text > processing. ;-) I think your are joking, since your post does not seem to indicate what you would do with the 8th bit of every byte, assuming your input is 8-bit bytes. Of course, 7-bit ASCII would be unusable when dealing with videos, j-pegs, even Word documents. What is the problem with simply reading binary disk blocks as 8-bit text using Sequential_IO, since Austin wants to use the attributes 'Pos and 'Val on the data stream? -- Eryndlia Mavourneen (KK1T)

Like all cryptography since the 1970's this crypto is is exclusively 'number-theoretic'.

Binary base is essential to the current block ciphers of NSA but is a cul-de-sac for any further resaerach.

Your admonition to increase the scope to cover all of Latin_1 has been implemented (C++ only uses ASCII as far as I can tell but I am open to correction here).

My stuff uses the decimal base and the geometry of planes in three dimensions as the encryption environment. The scope is limiltless for the everyday applications that all walks of life require.

GET and PUT together with 'Pos and 'Val kick-start the computation of the ciphertext for each character read in which is then completed in each single pass of the main loop i.e. read in, encrypt, written out as ciphertext end-to-end in one throw straight.

The plaintext for encryption is read in character by character from text files and is limited only by the computer capacity to store the growing arrays. This helps to make Ada a perfect language for cryptography.  

- There is no hard sell about this - just plain fact.

adacrypt

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Eryndlia Mavourneen]

On Wednesday, December 11, 2013 10:07:28 AM UTC-6, Austin Obyrne wrote:
> On Wednesday, December 11, 2013 3:14:37 PM UTC, Eryndlia Mavourneen wrote:
> 
> > On Wednesday, December 11, 2013 8:53:58 AM UTC-6, G.B. wrote: > why not > just require that encryption start at 7bit data units? > (This restriction helps keeping faulty produces in place, and it > allows continuing the ASCII caused destruction of well educated text > processing. ;-) I think your are joking, since your post does not seem to indicate what you would do with the 8th bit of every byte, assuming your input is 8-bit bytes. Of course, 7-bit ASCII would be unusable when dealing with videos, j-pegs, even Word documents. What is the problem with simply reading binary disk blocks as 8-bit text using Sequential_IO, since Austin wants to use the attributes 'Pos and 'Val on the data stream? -- Eryndlia Mavourneen (KK1T)
> 
> Like all cryptography since the 1970's this crypto is is exclusively 'number-theoretic'.
> 
> Binary base is essential to the current block ciphers of NSA but is a cul-de-sac for any further resaerach.
> 
> Your admonition to increase the scope to cover all of Latin_1 has been implemented (C++ only uses ASCII as far as I can tell but I am open to correction here).
> 
> My stuff uses the decimal base and the geometry of planes in three dimensions as the encryption environment. The scope is limiltless for the everyday applications that all walks of life require.
> 
> GET and PUT together with 'Pos and 'Val kick-start the computation of the ciphertext for each character read in which is then completed in each single pass of the main loop i.e. read in, encrypt, written out as ciphertext end-to-end in one throw straight.
> 
> The plaintext for encryption is read in character by character from text files and is limited only by the computer capacity to store the growing array.
This helps to make Ada a perfect language for cryptography.  
> 
> - There is no hard sell about this - just plain fact.
> 
> adacrypt

Agreed.  The problem, however, in using Text_IO is that terminators will be different on different systems and may even be handled differently on output by different compilers on the same system (if I recall correctly), and Text_IO attempts to interpret this data stream.  You need to use an I/O method which ignores the meaning of these characters and really does just treat the data as numbers, which is not what you are doing now with Text_IO. 

-- Eryndlia Mavourneen (KK1T)

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[G.B.]

On 11.12.13 16:14, Eryndlia Mavourneen wrote:
> What is the problem with simply reading binary disk blocks as 8-bit text using Sequential_IO, since Austin wants to use the attributes 'Pos and 'Val on the data stream?

The odd thing is that this discussion is about problems
caused by Text_IO, line endings, ^Z, and the alleged
portability of text files. Which, obviously, is not a fact.

First, potential BOMs added by smart editors or email clients,
automatic line ending transformation (unzip -a), etc.

What is more, if text is read using Text_IO by a program running
on this or that OS, calling this or that compiler's implementation
of Text_IO, of an ISO blessed language (Ada), then still the
results that are computed from the text could well be different.
That is, the interpretation of the message changes, which is
the one thing that text is supposed to prevent...

Not long ago, a magical calendar date (UTC) has passed, way into
the 21st century,

    Hurray : Time := Time_Of
      (Day     =>  (10 + 1),
       Month   =>  (10 + 2),
       Year    =>  (10 + 3) + 2000,
       Seconds => ((10 + 4) * Hour
                 + (10 + 5) * Minute
                 + (10 + 6) * s));

yet it seems we cannot reliably perform basic file I/O.

(Reading binary disk blocks as 8-bit text could work if reading
is not from the network .IFF: padding bits are handled and disk
block sizes agree everywhere and low numbered characters work
at the Text_IO layer. I guess.)

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
>
>> $ ./s
>> testing \n
>>
>> raised ADA.IO_EXCEPTIONS.NAME_ERROR : s.dat: No such file or directory
>>
>> and indeed s.dat does not exist.
>
> Drat.
>
> I forgot to add that you need to do (the equivalent of) "touch s.dat"
> before running the program (I thought it was quite long enough already
> without adding the Create/Open dance).

And now I look in the Ada95 AARM there's nothing that says what happens
if the external file to be Create'd already exists. I must have been
thinking of the Open/Create dance, or even Open-To-Append/Create.

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Wednesday, December 11, 2013 4:26:35 PM UTC, Eryndlia Mavourneen wrote:
> On Wednesday, December 11, 2013 10:07:28 AM UTC-6, Austin Obyrne wrote: > On Wednesday, December 11, 2013 3:14:37 PM UTC, Eryndlia Mavourneen wrote: > > > On Wednesday, December 11, 2013 8:53:58 AM UTC-6, G.B. wrote: > why not > just require that encryption start at 7bit data units? > (This restriction helps keeping faulty produces in place, and it > allows continuing the ASCII caused destruction of well educated text > processing. ;-) I think your are joking, since your post does not seem to indicate what you would do with the 8th bit of every byte, assuming your input is 8-bit bytes. Of course, 7-bit ASCII would be unusable when dealing with videos, j-pegs, even Word documents. What is the problem with simply reading binary disk blocks as 8-bit text using Sequential_IO, since Austin wants to use the attributes 'Pos and 'Val on the data stream? -- Eryndlia Mavourneen (KK1T) > > Like all cryptography since the 1970's this crypto is is exclusively 'number-theoretic'. > > Binary base is essential to the current block ciphers of NSA but is a cul-de-sac for any further resaerach. > > Your admonition to increase the scope to cover all of Latin_1 has been implemented (C++ only uses ASCII as far as I can tell but I am open to correction here). > > My stuff uses the decimal base and the geometry of planes in three dimensions as the encryption environment. The scope is limiltless for the everyday applications that all walks of life require. > > GET and PUT together with 'Pos and 'Val kick-start the computation of the ciphertext for each character read in which is then completed in each single pass of the main loop i.e. read in, encrypt, written out as ciphertext end-to-end in one throw straight. > > The plaintext for encryption is read in character by character from text files and is limited only by the computer capacity to store the growing array. This helps to make Ada a perfect language for cryptography. > > - There is no hard sell about this - just plain fact. > > adacrypt Agreed. The problem, however, in using Text_IO is that terminators will be different on different systems and may even be handled differently on output by different compilers on the same system (if I recall correctly), and Text_IO attempts to interpret this data stream. You need to use an I/O method which ignores the meaning of these characters and really does just treat the data as numbers, which is not what you are doing now with Text_IO. -- Eryndlia Mavourneen (KK1T)

That's useful to remember - may I counter this with the good news that whatever marker the encryption program uses (peculiar to that system as you point out that could vary)the same marker will be amenable to the decryption program because fortunately they are exact copies that comprise what I am calling the mutual databases.  

They are both created by the sending entity and an exact copy is made that is sent by a single secure delivery to the receiving entity in a one-off delivery (this is safe for the life of the secure loop as long as the entities keep their databases safe from ordinary criminal theft).

In passing, this concept of muutual databases totally obviates the historical problem of embedded key transport that was extremely vulnerable and took a lot of study time by researchers of the day.

Does this concept stand up in your estimation i.e, the system-specific EoF and EoM markers that you say can vary.

Interesting point solved I hope - do you accept this?

Austin

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Eryndlia Mavourneen]

On Wednesday, December 11, 2013 11:37:37 AM UTC-6, Austin Obyrne wrote:
> In passing, this concept of muutual databases totally obviates the historical problem of embedded key transport that was extremely vulnerable and took a lot of study time by researchers of the day.
> 
> Does this concept stand up in your estimation i.e, the system-specific EoF and EoM markers that you say can vary.
> 
> Interesting point solved I hope - do you accept this?
> 
> Austin

Only if you are dealing strictly with plain, vanilla text with no formatting as would be inserted by a word processor such as MS Word, OpenOffice, LibreOffice and others -- not to mention non-text files.  The additional information in these types of files potentially is critical to the receiver's understanding of the writer's intent.  More importantly perhaps, this approach deliberately excludes a vast number of file types, which, it seems, are cast away as being deemed unworthy of encryption.

Additionally, the work to change how the files are handled within the Ada program is so trivial that it boggles the mind why someone would choose to stick with Text_IO.

-- Eryndlia Mavourneen (KK1T)

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Clubley]

On 2013-12-11, Simon Wright <simon@pushface.org> wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> You assume tar available on the other end and that tar would recode
>> stuff.  As an example consider RSX-11M as a target. Your tar (if you
>> find one there) would have to translate file paths into something like
>> DK:[1,54]FOO.TXT (limited to RADIX-50 code set) and file bodies into
>> FILES-11 records.
>
> I'm glad I've never had to do that.
>

On VMS, the C RTL Unix to VMS translation layer would probably map a VMS
filename of the form DKA0:[SIMON]FOO.TXT to something like
/dka0/simon/foo.txt (although that would need double checking because on
VMS, I generally use VMS style filenames).

So, if we take the C RTL level mapping in VMS as a template, it would
probably be mapped within the language RTL on RSX-11M as something like
/DK/1,54/FOO.TXT or /DK/001054/FOO.TXT if that support was added.

As for the RMS side of things, I don't know what RMS attributes are available
on RSX-11M, but on VMS I would probably mark the file as something like
stream (not stream-lf) or as fixed size blocks with no carriage control.

IIRC, the tar versions I've seen on VMS treat any filename specification
without a leading slash as a path which is relative to the current directory
which bypasses much of the above problem.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Wednesday, December 11, 2013 5:54:44 PM UTC, Eryndlia Mavourneen wrote:
> On Wednesday, December 11, 2013 11:37:37 AM UTC-6, Austin Obyrne wrote: > In passing, this concept of muutual databases totally obviates the historical problem of embedded key transport that was extremely vulnerable and took a lot of study time by researchers of the day. > > Does this concept stand up in your estimation i.e, the system-specific EoF and EoM markers that you say can vary. > > Interesting point solved I hope - do you accept this? > > Austin Only if you are dealing strictly with plain, vanilla text with no formatting as would be inserted by a word processor such as MS Word, OpenOffice, LibreOffice and others -- not to mention non-text files. The additional information in these types of files potentially is critical to the receiver's understanding of the writer's intent. More importantly perhaps, this approach deliberately excludes a vast number of file types, which, it seems, are cast away as being deemed unworthy of encryption. Additionally, the work to change how the files are handled within the Ada program is so trivial that it boggles the mind why someone would choose to stick with Text_IO. -- Eryndlia Mavourneen (KK1T)

I agree with what you say but for the present we have to work with whay we've got but I agree - the writing is on the wall for change.

Clearly, all formatting is lost in current encryption and that must be changed in time to come which is why I say that 'IT' is still in very early days albeit half a century in existence.  We just cannot go on for very long more with primitive communications.  The whole of IT is in a state of flux and even I can see that change simply has to come.

This change will have to be totally accomodating to the layman however and not just the preserve of a few intellectuals who amuse themselves at the dizzy heights of news groups by swapping jargon that is often beyond the ken of ordinary readers.  That is not a swipe at anybody but it is true just the same.  It seems to be trendy to sound knowing and instead readers should go into 'teacher' mode when they post so that as many people as possible will benefit from what they say. It is not patronising to do this.

Good to hear.

Austin

Re: Binary versus text and compiler versions, was: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[erlo]

On 12/11/2013 12:37 PM, Austin Obyrne wrote:
> On Tuesday, December 10, 2013 11:08:40 PM UTC, Simon Clubley wrote:
>> On 2013-12-10, Randy Brukardt <randy@rrsoftware.com> wrote: > > But if I was writing this sort of code, I wouldn't worry about line endings > at all, and simply encrypt the file as binary data, using Stream_IO to read > it in and out. > Thank you. That's one of a number of things I don't understand about this. A serious encryption tool is going to treat the input as a opaque stream of bytes not as text. I don't encrypt pure text, but I _do_ encrypt full directory trees which may have a mixture of text and binary files within them. I don't understand how someone who claims to have invented something new cannot realise this. And to the OP: while I can certainly understand the desire to remain with Ada 95, 
> 
> 
> <what I don't understand is why you insist on using such a specific version <from a range of long obsolete compiler versions. Can you explain your <reasoning ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-<Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
> 
> Hi Simon,
> 
> The gnat 311.p compiler happens to be the one that I use to develop my cipher program source code in my three ciphers over 10 years ago.  
> 
> There is nothing binding about a compiler – if it works leave it alone unless you can benefit from the attributes of revised versions in 2013 there is no point in trying to improve on what you’ve got - each download, sale or whatever of my software comes with a gnat 311.p compiler provided ready for installing at the click of a mouse and is certain to work  – in passing this compiler loads like a treat in Windows XP, Vista, 7,& 8.  
> 
> There is nothing decadent about using an older compiler.  This compiler works even better than recent updated (revised) versions of the Ada language so there is no criticism that can be made on the back of being an older version.  There is no benefit whatever in using more recent compilers and as you can see it even leads to the trouble being discussed here.
> 
> It is not anachronistic to use an old compiler.  
> 
> •The ‘C’ language is still being used to write important components of systems and see how old that is.
> 
> Compilers in my understanding are updated solely so as to incorporate better ways of doing known criteria or of introducing totally fresh methods but if you don’t need these why change from what you’ve got?
> 
> The only downside of my scheme of disseminating my software with the same copied compiler in every case is that the compiler number is the same every time but is that an exploitable defect – No way do think so!
> 
> I hope this answers your question.
> 
> Austin
> 
Compilers has bugs too! One of the reasons to release a new version of a
compiler is to get rid of (some of) these bugs, which all users will
benefit of.

Erlo

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

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

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Monday, December 16, 2013 11:46:53 AM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@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 simon@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

Thanks for that Simon.

I am the first to admit that this cryptography has very high ciphertext expansion but I cannot understand it being 870 Megabytes for the example you gave. I have no doubt you are right.

The salient thing for me is in the crypto strength - this is theoretically unbreakable <= in the hands of the right people it has potential.

This is a great contribution - I salute you.

I think it is beyond me with my resources to do anything more - I have a cavalier attitude to cost and have always maintained that its security at any cost.

Most of what you say is technically beyond my ken also but its is very encouraging that you have not decided to condemn it out of hand as a lost cause like for instance the current complexity-theoretic crypto that is headed for the scrap heap.

Quite reamarkable that there was so much portability about the programs in such diverse environments.

Austin

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Monday, December 16, 2013 11:46:53 AM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@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 simon@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 never hoped to be competitive in implementing this crypto at the level of Ada programming and nuances of CS to be employed that you guys bandy about with such ease. 

A program that encrypted and decrypted (warts 'n all)was as much as I ever hoped for but it would have to demonstrate the potential of the vector mathematics as a medium for future.  

There still isn't a cipher out there that can be called really unbreakable and I envisage a huge surge at layman level in the next few years for something they can use and rely on whether or not they understan how it works.

Austin

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> I am the first to admit that this cryptography has very high
> ciphertext expansion but I cannot understand it being 870 Megabytes
> for the example you gave. I have no doubt you are right.

Each character is written as 3 integers, each occupying 11
characters. I've put a new line between every group of 3 integers,
whereas you put a new line where there's a new line in the original (I
think; anyway, not a good idea when the input isn't text), => 34
characters per byte (35 on Windows).

34 * 27_014_786 = 918_502_724 (875 MB).

> Most of what you say is technically beyond my ken also but its is very
> encouraging that you have not decided to condemn it out of hand as a
> lost cause like for instance the current complexity-theoretic crypto
> that is headed for the scrap heap.

My interest is in helping people to get code working right, not in
cryptography; I'd probably use GPG if I needed to.

It seems to me that yours is a symmetric-key scheme (I can't read the
documentation on your site because you've packaged up multiple PDF files
in one, which is a feature that's not supported by Mac Preview, and I'm
not going to install Acrobat).

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Monday, December 16, 2013 9:19:15 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > I am the first to admit that this cryptography has very high > ciphertext expansion but I cannot understand it being 870 Megabytes > for the example you gave. I have no doubt you are right. Each character is written as 3 integers, each occupying 11 characters. I've put a new line between every group of 3 integers, whereas you put a new line where there's a new line in the original (I think; anyway, not a good idea when the input isn't text), => 34 characters per byte (35 on Windows). 34 * 27_014_786 = 918_502_724 (875 MB). > Most of what you say is technically beyond my ken also but its is very > encouraging that you have not decided to condemn it out of hand as a > lost cause like for instance the current complexity-theoretic crypto > that is headed for the scrap heap. My interest is in helping people to get code working right, not in cryptography; I'd probably use GPG if I needed to. It seems to me that yours is a symmetric-key scheme (I can't read the documentation on your site because you've packaged up multiple PDF files in one, which is a feature that's not supported by Mac Preview, and I'm not going to install Acrobat).

<My interest is in helping people to get code working right, not in 
<cryptography; I'd probably use GPG if I needed to. 

Keep up the good work.

I'm not sure what I am - a problem solver I think - I don't admire cryptography - there is some powerful new mathenatics on the table here however that may take another half cenutury to be recognised - i.e. factoring a physical vector - the application to cryptography is only scratching the surface.

Generally the altruism of your group is fairly palpable - it comes across fairly noticeably.

I am putting pen to paper in a final condensation of the theory associated with this scheme and that is going to be it - finish.  My mind is in revolt. I would go back to sea but they won't take 80 year old Engineers any more.

I might spend a few moments thinking about reducing the cipheterxt volume that as you say is very large.

Thanks once more for your great help.

Austin.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Monday, December 16, 2013 11:46:53 AM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@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 simon@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

Having had time to assimilate your analysis properly I think the benefit for me is that I can now say to the crypto world that my ciphers in broad principle will run in any of the three main operating systems in main stream usage.

This is a huge plank being added to the platform.

The way things are going and the rate at which it is happening suggest to me that the problem of the large ciphertext is going to fall away in time to come with regard to assessing the usefulness of my cryptography.  These are problems to be solved but they have clear cut solutions that can be got to grips with by ordinary technology unlike the cryptography algorithms that is still in a different world.

For me personally, your analysis confirms my instincts that real life cryptography has benefited from my inventions.

One solution might be to use hexadecimal conversions on the ciphertext - not a great one I think.

* If you ever get the time and the inclination to perform a similar exercise as you have just done on the scalar cipher called “Scalable Key Cipher” you will find that the ciphertext volume is reduced by 2/3.  Each item of ciphertext is comprised of one only of the three large integers that comprises its stable companion vector ciphertext in that cipher called “SureCrypt”.

In passing, PGP crypto in practice has to be propped up by the RSA cipher to complete the digital signature part – it won’t be around in a few years time in my view.

http://www.adacryptpages.com/  - please see,

“Scalable Key Cipher “ – October 2013 for Windows XP, Vista, Windows 7 & 8.

Many thanks again for your great contribution – I might have had to wait years for what you have done in a few weeks.

Austin.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Monday, December 16, 2013 9:19:15 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > I am the first to admit that this cryptography has very high > ciphertext expansion but I cannot understand it being 870 Megabytes > for the example you gave. I have no doubt you are right. Each character is written as 3 integers, each occupying 11 characters. I've put a new line between every group of 3 integers, whereas you put a new line where there's a new line in the original (I think; anyway, not a good idea when the input isn't text), => 34 characters per byte (35 on Windows). 34 * 27_014_786 = 918_502_724 (875 MB). > Most of what you say is technically beyond my ken also but its is very > encouraging that you have not decided to condemn it out of hand as a > lost cause like for instance the current complexity-theoretic crypto > that is headed for the scrap heap. My interest is in helping people to get code working right, not in cryptography; I'd probably use GPG if I needed to. It seems to me that yours is a symmetric-key scheme (I can't read the documentation on your site because you've packaged up multiple PDF files in one, which is a feature that's not supported by Mac Preview, and I'm not going to install Acrobat).

I have re-encrypted a file in my program that is 31497 characters in length and measured the ciphertext at 0.99MB in my Windows 32 bit computer.

This is a far cry from the 875 MB you say it requires on your computer.

How come?

Austin

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Monday, December 16, 2013 9:19:15 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > I am the first to admit that this cryptography has very high > ciphertext expansion but I cannot understand it being 870 Megabytes > for the example you gave. I have no doubt you are right. Each character is written as 3 integers, each occupying 11 characters. I've put a new line between every group of 3 integers, whereas you put a new line where there's a new line in the original (I think; anyway, not a good idea when the input isn't text), => 34 characters per byte (35 on Windows). 34 * 27_014_786 = 918_502_724 (875 MB). > Most of what you say is technically beyond my ken also but its is very > encouraging that you have not decided to condemn it out of hand as a > lost cause like for instance the current complexity-theoretic crypto > that is headed for the scrap heap. My interest is in helping people to get code working right, not in cryptography; I'd probably use GPG if I needed to. It seems to me that yours is a symmetric-key scheme (I can't read the documentation on your site because you've packaged up multiple PDF files in one, which is a feature that's not supported by Mac Preview, and I'm not going to install Acrobat).

< Each character is written as 3 integers, each occupying 11 characters

An integer occupying 11 characters like say 21474836470 would not be possible on a 32-bit Windows computer where the largest positive integer is 2147483647 and it would cause a "Constraint Error" to appear  due to integer overflow.

Am I reading you right?

Austin.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Monday, December 16, 2013 9:19:15 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > I am the first to admit that this cryptography has very high > ciphertext expansion but I cannot understand it being 870 Megabytes > for the example you gave. I have no doubt you are right. Each character is written as 3 integers, each occupying 11 characters. I've put a new line between every group of 3 integers, whereas you put a new line where there's a new line in the original (I think; anyway, not a good idea when the input isn't text), => 34 characters per byte (35 on Windows). 34 * 27_014_786 = 918_502_724 (875 MB). > Most of what you say is technically beyond my ken also but its is very > encouraging that you have not decided to condemn it out of hand as a > lost cause like for instance the current complexity-theoretic crypto > that is headed for the scrap heap. My interest is in helping people to get code working right, not in cryptography; I'd probably use GPG if I needed to. It seems to me that yours is a symmetric-key scheme (I can't read the documentation on your site because you've packaged up multiple PDF files in one, which is a feature that's not supported by Mac Preview, and I'm not going to install Acrobat).

My displayed output is screened as three columns of integers of about 7-8 digits each.  This has to be the case so as to be readable by viewers as three-dimensioned vectors.  It is not beneficial to run these into one long column because they are then unreadable.

I think also you may have under-divided by 1000 and 875 might be 0.875 MB ?  which corresponds more with my measured 0.99 MB for the whole file of 31497 characters (which by coincidence is experimental encrypted Ada source code but that is incidental here)

It looks to me that the important criteria is the volume of ciphertext that must be transmitted by the infrastructure – 0.99MB for 31497 characters isn’t as bad as you make it look at 875 MB??.

Could you please check your computations again.

Give a dog a bad name and you hang him!

Austin

PS - putting a new line between each row of three integers is not necessary for screening and is loading up the program ciphertext unnecessarily internally?

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> I have re-encrypted a file in my program that is 31497 characters in
> length and measured the ciphertext at 0.99MB in my Windows 32 bit
> computer.
>
> This is a far cry from the 875 MB you say it requires on your computer.

What I originally said was "the encrypted SureCrypt85610.zip comes out
at about 870 megabytes" - SureCrypt85610.zip is 27 MB.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> On Monday, December 16, 2013 9:19:15 PM UTC, Simon Wright wrote:

> < Each character is written as 3 integers, each occupying 11 characters
>
> An integer occupying 11 characters like say 21474836470 would not be
> possible on a 32-bit Windows computer where the largest positive
> integer is 2147483647 and it would cause a "Constraint Error" to
> appear due to integer overflow.

But the largest *negative* integer is -2147483648.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> My displayed output is screened as three columns of integers of about
> 7-8 digits each.  This has to be the case so as to be readable by
> viewers as three-dimensioned vectors.  It is not beneficial to run
> these into one long column because they are then unreadable.

I'd have thought that the only reason to look at the encrypted data
would be to debug it. Users would never want to.

> PS - putting a new line between each row of three integers is not
> necessary for screening and is loading up the program ciphertext
> unnecessarily internally?

By about 3%. One would save much more (66%) by encoding as binary.

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Wednesday, December 18, 2013 8:35:16 AM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > I have re-encrypted a file in my program that is 31497 characters in > length and measured the ciphertext at 0.99MB in my Windows 32 bit > computer. > > This is a far cry from the 875 MB you say it requires on your computer. What I originally said was "the encrypted SureCrypt85610.zip comes out at about 870 megabytes" - SureCrypt85610.zip is 27 MB.

Hi Simon,

Thanks for clearing that up i.e. the *entire Zip file is 27MB which is about right from memory but this includes all the anciliary subprograms + three main programs

It is of some concern to me that the ciphertext was appearing to be responsible for all of it.

Although the ciphertext is relatively large in vector cryptography that has to be expected as the price to pay fro absolute and total obfuscation.

I am happy enough at the present expansion ratio but I will be working on ways of refining that.  I don't consider it serious.

Regards - Austin

Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.

[Austin Obyrne]

On Wednesday, December 18, 2013 9:02:05 AM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > My displayed output is screened as three columns of integers of about > 7-8 digits each. This has to be the case so as to be readable by > viewers as three-dimensioned vectors. It is not beneficial to run > these into one long column because they are then unreadable. I'd have thought that the only reason to look at the encrypted data would be to debug it. Users would never want to. > PS - putting a new line between each row of three integers is not > necessary for screening and is loading up the program ciphertext > unnecessarily internally? By about 3%. One would save much more (66%) by encoding as binary.

<I'd have thought that the only reason to look at the encrypted data 
<would be to debug it. Users would never want to. 


Yeah, in practice that would be the case.  It is being done here to stifle criticism and show proof of delivery.