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=0.1 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM,HK_RANDOM_FROM autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Denis McMahon Newsgroups: comp.lang.ada Subject: Re: Ada Connections to this Crypto. Date: Tue, 23 Dec 2014 01:37:58 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1a2fea61-bcc1-43a9-b6e3-edf474308402@googlegroups.com> <5d31987b-b96b-481b-ac4d-f87114257bb4@googlegroups.com> <87vblc7mwh.fsf@ixod.org> <9ee2f572-0f95-4f4c-bcc8-83debae7868d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 23 Dec 2014 01:37:58 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="66ffcfa4470a58bcddbdcd1913f98ab4"; logging-data="22109"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/LQVF0D3LhMRllzsh7QaydT8d019qCxqI=" User-Agent: Pan/0.136 (I'm far too busy being delicious; GIT 926a150 git://git.gnome.org/pan2) Cancel-Lock: sha1:GUlsQDa/+SS9wCt9O/OJbOfZ4QM= Xref: news.eternal-september.org comp.lang.ada:24202 Date: 2014-12-23T01:37:58+00:00 List-Id: On Tue, 16 Dec 2014 00:53:03 -0800, Austin Obyrne wrote: > I don't profess to be anything in the way of an Ada developer or a > cryptography developer but when one comes up with an algorithm that is > demonstrably irreversible then that's it... No, that's not it. A fairly basic analysis of adacrypt shows that irrespective of whether it is a secure encryption system or not, it fails to meet common user requirements for encryption in at least 5 very fundamental ways: ---------------------------------------------------------------- (1) Key management. It appears that your adacrypt incoporates the key in the compiled program as a piece of ada code. This means that any two people who wish to exchange data using this encryption both need to compile their code against the same key files (you appear to call these four files Alices_Digital_Signature.adb, Alices_Encryption_Numbers.adb, Alices_Digital_Signature.ads, and Alices_Encryption_Numbers.ads). This is a wholly unacceptable means of operation of an encryption system, as the number of copies of the encryption and decryption programs that each user has expands as the number of people using the encryption. You should re-write your code in such a way that each user only needs a single copy each of the encryption and decryption code, and specifies the appropriate key file(s) to use at run time. (2) The Authenticity Concept Current encryption methods support proof of authenticity as well as protection from eavesdropping, using the public / private key pair. For example, if Alice encrypts data using Bob's public key and Alice's private key, then the data can only be unencrypted using, in the correct order, Bob's private key and Alice's public key. This means that only Bob can recover the data (by using his private key), and that he knows it was genuinely from Alice (as he also required her public key, proving it was encrypted with her private key). It appears that adacrypt uses a single key per user, so that if Jim exchanges encrypted data with Alice using Alice's key, and with Bob using Bob's key, he can then pretend to be Alice to Bob, or pretend to be Bob to Alice. The only solution to this in Adacrypt is for each pair of people to have a separate key, which creates another key administration issue, namely that every pair of people have to agree on a unique to that pair key, instead of each person having a two part public / private key, the public part they can share with all and sundry as long as they keep the private part secret to themselves. (3) Character Set Limitation Current encryption systems support data where each character is in the ascii range 0 .. 255 inclusive. Your adacrypt code is currently limited to data where each character is in a restricted subset of this range, apparently 30 .. 129. As has been explained to you in the past on multiple occasions, in this area your code represents a retrograde step when compared with existing cryptosystems, and until you can resolve this issue the only person who it appears will be using your code is yourself. (4) Streaming Communication Current encryption requirements are generally internet based, and relate to the encryption of data streams between two users. Until such time as you are able to write your code to provide for such a usage case, your encryption system, no matter how wonderful it is, will be of little or no interest to anyone who wants to encrypt data. (5) Data Expansion. On a small sample of data provided by you, an expansion factor in the volume of data to be transmitted and hence the bandwidth required of 14 was observed. This is wholly unacceptable to the majority of users. Modern cryptosystems tend to have an overhead of the order of less than 10% of the amount of data to be transmitted, rather than 1300%. Again, should you wish your cryptosystem to be adopted you need to address this issue, rather than just saying in a rather dismissive manner "buy more bandwidth / hard disks". ---------------------------------------------------------------- Note that these are 5 very fundamental issues (and there may well be others) that will prevent the uptake of adacrypt either commercially or through the FOSS movement, and are wholly irrelevant of whether it is a secure encryption system or not. Only if you can successfully address these issues are people likely to be interested in even considering whether it is a viable encryption system or not. Your continued dismissal of these issues is ensuring that adacrypt will never be recognised as an encryption system. The solution to this issue is in your hands and your hands alone, you must address and resolve these issues to make adacrypt an encryption system that has the usability features that encryption users insist upon. -- Denis McMahon, denismfmcmahon@gmail.com