Prev: My Cryptography that is Currently on the Table.
Next: Recommend AES Program, Please
From: Gordon Burditt on 4 Jul 2010 23:01
>There will always be a need for the cheapest cryptography available
>that will serve the needs of commerce at some right price and give the
>required degree of security for the required cover time.

E-commerce, especially over the Internet, needs public-key cryptography.
Your cryptography, theoretically unbreakable or not, does not provide
that. A lot of the job of web-based SSL is to communicate your credit
card info to the thief you are doing business with before the other
thieves get hold of it. SSL also needs to encrypt images, which for
some odd reason your cryptography won't do, due to a silly design
decision. There's no inherent reason it can't be modified to do
raw binary.

>Anything more
>than the required degree of security and the required cover time in
>commerce is redundant cover and can be a very expensive waste.

Your cryptography is far too complicated to use for the average
web-user, especially in terms of setting up and keeping track of
keying material set up with many, many correspondents. The typical
web user does not have a secure channel, and they don't know much
about key handling. Their computers, however, may be infected with
viruses which will likely be written to steal keys should your
cryptography be used in SSL.


>In the
>case of national security however cover time is never-ending and the
>degree of security should be nothing less than theoretically
>unbreakable � i.e. perfect secrecy of communication of information at
>least.

For at least *some* situations, e.g. embassy to home government or
military base to military base, the required secure channel for
sending keying material is available (at least before all hell
breaks loose) and existing practice (e.g. diplomatic courier pouches).

However, your cryptography is vulnerable to corrupted messages,
messages received out of order, or missing messages, something
likely to happen when all hell breaks loose, accompanied by weapons
systems blowing things up, deliberate jamming, and EMP from nuclear
weapons. This is just the time when the secure channel (diplomatic
couriers) will prove to be too slow and unreliable.

Your cryptography does not even preserve line lengths, and you
(according to you) insert line breaks every 77 characters (a
particularly stupid choice). This I believe, if deployed in a
military situation, will eventually cost lives by changing the
meaning of the message.

>At present, national governments are in the parlous state of never
>knowing if hitherto �practically� unbreakable ciphers have indeed
>being broken in the meantime by enemy powers who are now quietly
>reading their intercepted secret messages. The only antidote to that
>event is for national governments to use theoretically unbreakable
>security as the minimum degree of security at all times.

No, that's not an antidote. Theoretically unbreakable cryptography
may be broken by practical means, such as stealing a copy of the
key, rubber hose cryptography, torture, or even exotic means used
by the press such as detecting a spike in nighttime pizza delivery
orders in areas around the Pentagon. And that probably *can't* be
fixed by encrypting pizza orders from the Pentagon to pizza-delivery
places.

>Only that
>will always ensure that their secret communications to other countries
>are completely safe. That kind of security is not available to any
>country however at the present time.

If theoretically unbreakable cryptography provides "secret
communications that are completely safe", then the One Time Pad
*is* available today for this purpose. It has a simple proof of
security that yours doesn't. Practical considerations may result
in a choice not to use it. Embassies are one setup where it may
be practical to deal with the issue of handling large keys.

>The aim here therefore, is to create theoretically unbreakable
>cryptography at any cost for national security and hope that this cost
>will be acceptably low at the same time for commerce to be able to
>afford it also in all day-to-day running, otherwise commerce is just

Your cryptography has a constant extra cost because of your
shoot-self-in-foot decision to not permit (and *silently* corrupt)
encryption/decryption of arbitrary binary patterns such as images,
audio recordings, word processing documents, and intercepted emails
in foreign languages that don't stick to the printable subset of
ASCII.

>as well off staying with existing cryptography that is being called
>�practically� unbreakable. Although only �practically� unbreakable in
>name that cryptography is virtually unbreakable in practice. The only
>disturbing thing about �practically unbreakable� cryptography is the
>fact that nobody knows what trumps the enemy is holding in the way of
>secret advances they may have made in cracking ciphers such as the RSA
>cipher and AES that hitherto governments regarded as unbreakably safe.
>Only theoretically unbreakable ciphers can be considered totally safe
>in this respect.

And those are also vulnerable to spies and ways of stealing the key.
If the spy is careful, you won't know the key was stolen.

>There is no selfish pursuit of greedy material gain by me in this
>respect in the cryptography that I am promoting as either vector
>cryptography http://www.adacrypt.com or modular cryptography
>http://www.scalarcryptography.co.uk that both operate by mapping
>plaintext to widely dispersed points in space thus putting
>cryptanalysis beyond the pale of all mathematics in terms of inversion
>methods.
>These cipher designs both use mutual database technology to
>implement the mathematical one-way functions and randomness that are
>the securing basis of these crypto types.

"mutual database technology" is vulnerable to getting out of sync
if you decrypt a message twice, receive messages out of order, a
message goes missing and you try to decrypt later ones, or messages
are corrupted.

Your use of the term "one-way functions" here is not standard
cryptography terminology. One-way functions have no easy inversion,
*with or without* a key.

>Mathematical inversion of
>ciphertext is totally disabled by this design of cryptography.

>The ciphers to hand are intended to be nothing more than feasibility
>models that say �the proof of the pudding is in the eating� i.e. they
>demonstrate the realisation of the mathematical claim into de facto
>ciphers. I have no pretensions to software engineering or
>infrastructure management but my claim is that only when the
>mathematical core is demonstrated as being theoretically unbreakable,
>is all else then made possible and not before this.

"theoretically unbreakable" has a high cost in terms of the amount
of shared key required (the sum of the length of all the messages
you will ever send). For some applications, this is too high a
cost.

Some applications need to send and receive raw binary data. Your
cryptography does not handle that (for a silly reason of yours -
there's no reason it couldn't be modified to handle this).

>It is fully understood by me that clever software engineering by these
>experts will greatly enhance all aspects of the working efficacy of
>the software per se that is to hand as up and running programs, as
>well as optimising the portability of the software as it stands and
>also, an input of experienced infrastructure management will work
>wonders on both the considerable tertiary system security and the
>electronic transmission efficacy of the overall crypto schemes.
>
>Even as it stands, either of these crypto scheme types is quite viable
>as a home-grown DIY crypto scheme that any non-specialist management
>group like say a corporate commercial company wanting to set up and
>manage their own crypto network could do on thier own, with minimal
>knowledge of cryptography. It is well within the capability of an
>average office administrator to do this.
>
>I am confident that the running costs of this simple transparent
>scheme that provides maximum security i.e. theoretically unbreakable
>class of security, is eventually going to be so cheap as to become the
>first choice for both commercial and national secure communications in
>time. No on-site specialists are needed for the day-to-day running of
>a scheme apart from say an initial systems-analyst/cryptographer input
>at the outset just to get it all working. I envisage such a scheme as
>having about the same daily management complexity needs as say a
>typical on-line banking scheme.

In other words, you don't want to talk about all the problems about
exchanging keys securely, not getting out of sync when communication
screws up, and that hidden secure channel you try not to talk about.

You will constantly need tech support to explain why word-processing
documents, images, and other similar raw-binary files are silently
corrupted. Soon you'll need to handle a larger character set such
as UTF-8. Disallowing stuff outside the printable characters of ASCII
will be no more tolerable than disallowing vowels.

>There is no argument for continuing current crypto schemes that
>require a lot of user-assistance and are only practically unbreakable
>at the end of the day unless they are very much cheaper than what�s on
>offer here - I doubt this very much - adacrypt

The cost of a crypto scheme is infinite if it fails to work for
the application. Your cryptography fails:

- It can't do public-key cryptography.
- It can't work without a pre-shared key or secure channel transmitting
at least as much volume as the message traffic (why not just use
the secure channel?)
- It only does the printable subset of ASCII and corrupts line length
and any characters outside the printable subset of ASCII (like most
of adacrypt's Usenet posts).
- It is vulnerable to getting out of sync (denial-of-service) if
messages are lost, duplicated, received out of order, or you try
to decode a fake message from the enemy.

 | 
Pages: 1
Prev: My Cryptography that is Currently on the Table.
Next: Recommend AES Program, Please