Re: Ada Connections to this Crypto.

[Denis McMahon <denismfmcmahon@gmail.com>]

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