From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.120.99 with SMTP id lb3mr24546291obb.10.1418633444206; Mon, 15 Dec 2014 00:50:44 -0800 (PST) X-Received: by 10.140.108.161 with SMTP id j30mr419qgf.42.1418633444087; Mon, 15 Dec 2014 00:50:44 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!h15no10528874igd.0!news-out.google.com!r1ni52qat.1!nntp.google.com!s7no7409256qap.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 15 Dec 2014 00:50:43 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=5.80.153.30; posting-account=pmkN8QoAAAAtIhXRUfydb0SCISnwaeyg NNTP-Posting-Host: 5.80.153.30 References: <1a2fea61-bcc1-43a9-b6e3-edf474308402@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <021184f0-18ef-40bc-ba62-fd307998fe1c@googlegroups.com> Subject: Re: Ada Connections to this Crypto. From: Austin Obyrne Injection-Date: Mon, 15 Dec 2014 08:50:44 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4519 X-Received-Body-CRC: 3565505011 Xref: news.eternal-september.org comp.lang.ada:23992 Date: 2014-12-15T00:50:43-08:00 List-Id: On Sunday, December 14, 2014 8:28:36 PM UTC, Simon Wright wrote: > Austin Obyrne writes: >=20 > > 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. >=20 > 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. >=20 > :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 s= tandard enumeration type which happily is the ASCII standard today (ignore = the extension to the full Latin_1 which my be marked - 'proved').=20 Because it is a universal standard there is no need for the entities to sen= d copies of it to each other. This is a hugely important benefit that is i= nvariably taken for granted because of the sheer familiarity that we all en= joy with it - i.e. because we are using 'standard' computers and 'standard'= programming languages that have ASCII as the inbuilt code the intrinsic co= mparator 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 ubiquit= ous 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 secur= ed against theft. Consider now the case when the entities deliberately eschew this mutual sta= ndard and opt instead for a user-defined enumeration type instead of ASCII = that evolves from using sequential_IO instead of Text_IO (which already ena= bles perfect sequential calling of the plaintext items for encryption anywa= y) then this new non-standard comparator cannot be assumed anymore and a co= py of Alice's customized "Information Interchange" encryption alphabet what= ever 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 l= iability that needs protection itself while in transit instead of helping t= o provide protection as it would in the normal scheme of things.=20 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 recommen= ded and I would certainly rule it out for now at least if not for ever in m= y 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. =20 *It may well be very worthwhile in very important super cases to do just th= at 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. =20 I don't think the readers involved are thinking that far ahead. Thanks for your input. =20 adacrypt