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 <clubley@remove_me.eisner.decus.org-Earth.UFP>]

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