From: Mok-Kong Shen on
adacrypt wrote:

> I forgot to say that this modus operandi (reading in from batch files
> in Ada-95) is at the core of several ciphers that I have written - I
> would never consider changing it

Then the only proper place of your post would have been comp.lang.ada.
From: crisgoogle on
On Jun 15, 5:01 am, adacrypt <austin.oby...(a)hotmail.com> wrote:
> On Jun 15, 11:12 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
>
> > adacrypt worte:
>
> > >......  - makes a copy file of an
> > > existing external file - the application to cryptography is obvious. –
>
> > I don't understand this at all. Could you elaborate on your point?
>
> > M. K. Shen
>
> Also,
> I forgot to say that this modus operandi (reading in from batch files
> in Ada-95) is at the core of several ciphers that I have  written - I
> would never consider changing it because it is so logical and
> transparent - my encryption program is in essence a pair of large
> nested loops, the outer loops calls in a character from the externally
> prepared batch file in my folder(directory), the inner loop then
> transforms this character by operating on its ASCII denary value in a
> number of ways until the transformation into ciphertext is completed
> in one pass of the inner loop and it then writes (outputs) the
> ciphertext to  a growing file of ciphertext in another named file in
> my directory (folder).
>
> The loop is controlled i.e. terminated by the Ada End_of_Line command
> that terminates the inside loop (transforming the current character)
> and finally by the End_of_File command that terminates the outer loop
> when the last character has been read in and encrypted by the inside
> loop.
>
> This model is so good that I cannot think of anything better as an
> encryption program.

<snip>

Nope, you have this the wrong way around:

You can't think of anything better, therefore it looks good.

You're just getting downright silly if you think reading and writing
a file byte-by-byte is somehow interesting. Look up "cp", "copy", or
"file filter".

From: jbriggs444 on
On Jun 15, 5:44 am, adacrypt <austin.oby...(a)hotmail.com> wrote:
> WITH Ada.Text_IO;
> PROCEDURE Batch_Encryption_Program_Mark_1 IS
> _____________________________________________________________________
> --|  A demonstration of file handling i.e. reading in from a batch
> file of plaintext
> --|
> _____________________________________________________________________
>   MaxName : Constant Positive := 80;
>   SUBTYPE NameRange IS Positive RANGE 1 .. MaxName;
>   InFileName : String(NameRange) :=(OTHERS => '#');
>   OutFileName: String(NameRange) :=(OTHERS => '#');
>   InNameLength: NameRange;
>   OutNameLength: NameRange;
>   InData: Ada.Text_IO.File_Type;
>   OutData: Ada.Text_IO. File_Type;
>   --NextCh: Character;-- That will be the variable name of each
> character read in
>
> BEGIN  -- Batch_Encryption_Program_Mark_1
>     -- get input file name and open it
>   Ada.Text_IO.Put(Item => " PLease enter the name of the file to
> encrypt >");
>   Ada.Text_IO.New_Line(2);
>   Ada.Text_IO.Put(Item => " ");
>   Ada.Text_IO.Get_Line(Item => InFileName, Last=> InNameLength);
>   Ada.Text_IO.New_Line;
>   Ada.Text_IO.Open(File => Indata,
>   Mode => Ada.Text_IO.In_File,Name => InFileName(1 .. InNameLength));
>
> --------------------------------------------------------------
>
> This declaration above will get you any file in your directory – the
> file must exist first of all and if there’s a file extension it must
> be quoted.
>
> This simple declaration is all that is needed to get you started
> encrypting a file of plaintext – it can be repeated in all programs as
> a standard declaration every time.
>
> This an excerpt from “Ada-95 – Problem Solving and Program Design”
> Feldman and Koffman.  It makes file handling very easy – works every
> time – try it ! –

I rather doubt that it is an exerpt. The upper case L in the prompt
string is a giveaway.

If anyone cares, a more complete and accurate excerpt can be found
at:

http://faculty.cs.wwu.edu/reedyc/AdaResources/FK3-W95_SourceHTML/copy_file.adb.html

[See relevant extract at the end of this post]

The interesting part of the copy operation is a simple character by
character read
together with an insertion of a newline in the output whenever a
newline is found in
the input.

As long as the external file model is accurately represented within
the Ada
Text_IO model, this copy scheme seems pretty robust.

As per the Ada spec the question of accurate representation is not a
language
question. It's an implementation question. The killer situation for
a copy
operation would be the existence of two files that are different from
the
point of view of the external file system but which are
indistinguishable
from the point of view of the Text_IO model.

The kinds of corner cases to look for would be, for instance, null
bytes
preceding the line terminator (in, for instance implementations using
RMS with VAX/VMS with stream format files), a line terminator at EOF
or BOF, partial line terminators such as a <LF> with or without a
preceding
<CR> or a <CR> with or without out a subsequent <LF>, in-band EOF
characters on a file system with out-of-band EOF detection and in-band
EOL characters on a file system with out-of-band EOL detection.

Sequential_IO is clearly a better fit for the typical "file as a
sequence of octets" external file model than Text_IO.

>
> An invaluable exercise is to work example 10.10 on P. 451 – this
> worked example gives complete cource code - makes a copy file of an
> existing external file - the application to cryptography is obvious. –
> your’s humbly

The rubber meets the road at:

LOOP
EXIT WHEN Ada.Text_IO.End_of_File(File => InData);
LOOP
EXIT WHEN Ada.Text_IO.End_of_Line(File => InData);

Ada.Text_IO.Get(File => InData, Item => NextCh);
Ada.Text_IO.Put(File => OutData, Item => NextCh);

END LOOP;

Ada.Text_IO.Skip_Line(File => InData);
Ada.Text_IO.New_Line(File => OutData);
END LOOP;

This being a cryptography newsgroup rather than an Ada programming
newsgroup, I'll bow out and endeavor to make this my only
"Adacrypt" posting for the year.
From: rossum on
On Tue, 15 Jun 2010 10:06:03 -0700 (PDT), jbriggs444
<jbriggs444(a)gmail.com> wrote:

>I'll bow out and endeavor to make this my only
>"Adacrypt" posting for the year.
Very good advice. I think I am about halfway through the 22nd
century. :(

rossum

From: Gordon Burditt on
>> This model is so good that I cannot think of anything better as an
>> encryption program.
><snip>
>Nope, you have this the wrong way around:
>
>You can't think of anything better, therefore it looks good.
>
>You're just getting downright silly if you think reading and writing
>a file byte-by-byte is somehow interesting. Look up "cp", "copy", or
>"file filter".

adacrypt thinks it's appropriate to design an encryption program
that, during an encrypt/decrypt cycle, deletes all the newlines and
arbitrarily re-inserts them every 77 characters. I suspect that
copying a file, while preserving newlines, is beyond his capabilities,
so he refuses to see why mangling plaintext is a problem. If he
can't copy a file, it's hard to add in encryption using that as a
base.