Re: Ada Connections to this Crypto.

[Austin Obyrne <austin.obyrne@hotmail.com>]

On Sunday, December 14, 2014 8:28:36 PM UTC, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> > I have been harassed by some readers with claims that there are ways
> > by which 'any' data can be called (whatever that means)and encryption
> > will still work.  They seem to be saying that this is done by
> > user-defined enumeration types that can be used instead of ASCII or
> > Latin-1.
> 
> I rather think I take offence at that. You imply that the program I
> wrote using your crypto to encrypt/decrypt a ZIP file (which is anything
> but Latin-1 text!) was bogus.
> 
> :plonk:

Oh Gosh NO,
lemme explain.
What I am getting at is this.

In my mind -

In cryptography when a data item is called in for encryption the 'coinage' i.e. the currency for mutual understanding in the obfuscation scheme is a standard enumeration type which happily is the ASCII standard today (ignore the extension to the full Latin_1 which my be marked - 'proved'). 

Because it is a universal standard there is no need for the entities to send copies of it to each other.  This is a hugely important benefit that is invariably taken for granted because of the sheer familiarity that we all enjoy with it - i.e. because we are using 'standard' computers and 'standard' programming languages that have ASCII as the inbuilt code the intrinsic comparator for buying and selling is ASCII.

I repeat we do not have to send copies of our comparator in cryptography to each other with each message so long as we are both using the same ubiquitous standard that each entity can safely assume the other is also using. It is virtually a public key and it travels free without any need to be secured against theft.

Consider now the case when the entities deliberately eschew this mutual standard and opt instead for a user-defined enumeration type instead of ASCII that evolves from using sequential_IO instead of Text_IO (which already enables perfect sequential calling of the plaintext items for encryption anyway) then this new non-standard comparator cannot be assumed anymore and a copy of Alice's customized "Information Interchange" encryption alphabet whatever it is must be sent by secure means to Bob to enable him to decrypt her ciphertext. What was previously a free and helpful tool has now become a liability that needs protection itself while in transit instead of helping to provide protection as it would in the normal scheme of things. 

There may be exceptions to this like your ZIP file model- since this debate is not fully researched - but at the present time it is not to be recommended and I would certainly rule it out for now at least if not for ever in my cryptography.

I don't accept the inevitable trivial curio exceptions that always arise in discussions like this as valid argument which of course your ZIP model is not.  

*It may well be very worthwhile in very important super cases to do just that i.e. to contrive a non-standard as the comparator - a future researcher will of course keep an open mind but in broad principle it is NO from me to any such scheme at this time.  

I don't think the readers involved are thinking that far ahead.

Thanks for your input.  

adacrypt