Prev: The Winds of Change - The Three Faces of Cryptography.
Next: General factoring result for k^m = q mod N
From: Gordon Burditt on 11 Jun 2010 17:32
>Seriously minded people would surely be expected to want nothing less
>than totally unbreakable cryptography as the only standard worth
>taking on board but that is clearly not the case in this news group.

Totally unbreakable cryptography comes with too much baggage and
administrative problems to be usable. The One Time Pad has been
around for a long time, and it never caught on, largely for the
reason that you have to exchange, and then store, a very large
amount of key material. Any other unbreakable cryptography will
have the same problem. There's also the problem of being sure you
do not use parts of the key more than once, and maintaining sync
between the two parties communicating in the face of dropped messages,
duplicated messages, messages out of order, corrupted messages, and
malicious faked messages intended to throw communication out of
sync.

It's also true that a large amount of communication that you want
to be secure for e-commerce occurs between strangers, who DON'T
have keying material exchanged in advance.

>This is not a criticism but the reality is that not everybody seems to
>want that to happen for reasons that are not clear and since we live
>in a democracy they are entitled to act the way they want within the
>law. It is useful therefore to rationalise the status quo and see
>where we are working with regard to the overall analysis of the
>industry from a scientific point of view.

>If anybody wants to pursue
>practically unbreakable (less than perfectly unbreakable cryptography)
>as a selfish cultural pursuit say, then so be it but it needs to be

Less than perfectly unbreakable cryptography is a reasonable engineering
choice for many applications (actually almost all of them, given the
limitations of perfectly unbreakable cryptography).

>made clear to new readers that this something less than the more
>serious end-point of perfect secrecy of communications that is the

Considering the number of discussions on what it takes to brute-force
various ciphers, anyone who doesn't get that they don't provide
perfectly unbreakable cryptography hasn't been paying attention.

>only standard to be aimed at for main stream national and important
>commercial levels.

Perfect secrecy of communications is *NOT* the only standard to be
aimed at. For e-commerce with the general public, the goal is
perfect secrecy of communications *that can be operated by stupid
monkeys (stupid even compared to average pond scum)*, from computers
likely to be infected with viruses and spyware, and with users who
can easily be fooled into giving up their keys by sending them an
email purportedly from Nigeria offering them imaginary huge piles
of money. Or they can be fooled into giving away passwords to
anyone who calls themselves an administrator. Hint: that's
unachievable. One of the things you give up is perfect secrecy of
communications when you know you can't keep the key secure anyway.


>The peripheral secure communications of the present industry i.e. the
>razzmatazz show case that includes news groups, dedicated associations
>purporting to represent research, academies offering courses by
>internal research team members, promoters of conferences worldwide, is
>indeed an industry that is living off its defects instead of its
>successes.

A news group is not an industry.

>A euphemism of �the emperor�s new clothes� is a quite apt
>description � but the emperor is clearly stark naked and nobody
>seemingly wants to give up his long-standing hobby of fantasy
>cryptography by admitting to this.

The industry offering perfect secure communications also has no
clothes when it comes to admitting the need for a huge-bandwidth
secure channel, vulnerability to getting out of sync, and a lot of
administrative problems involving not re-using the same portion of
the key more than once. It's worse when adacrypt is denying that
it is necessary to not re-use the same portion of the key more than
once.

>It is surely time to get real about the status quo.

It is also time to get real about the enormous disadvantages of
perfectly secure cryptography, like requiring a secure channel for
key exchange which often isn't available or isn't secure.

One of the really severe disadvantages of adacrypt's cryptography
is that it is claimed to require a "keyboard operator", something
unavailable on an e-commerce server. This flaw is probably fixable
without too much trouble. Another problem is that, according to
adacrypt, it only accepts subsets of the ASCII character set as
plaintext while leaving out some of the most important ASCII
characters, such as newline, tab, and carriage return.

From: adacrypt on 12 Jun 2010 03:17
On Jun 11, 10:32 pm, gordonb.gl...(a)burditt.org (Gordon Burditt) wrote:
> >Seriously minded people would surely be expected to want nothing less
> >than totally unbreakable cryptography as the only standard worth
> >taking on board but that is clearly not the case in this news group.
>
> Totally unbreakable cryptography comes with too much baggage and
> administrative problems to be usable.  The One Time Pad has been
> around for a long time, and it never caught on, largely for the
> reason that you have to exchange, and then store, a very large
> amount of key material.  Any other unbreakable cryptography will
> have the same problem.  There's also the problem of being sure you
> do not use parts of the key more than once, and maintaining sync
> between the two parties communicating in the face of dropped messages,
> duplicated messages, messages out of order, corrupted messages, and
> malicious faked messages intended to throw communication out of
> sync.
>
> It's also true that a large amount of communication that you want
> to be secure for e-commerce occurs between strangers, who DON'T
> have keying material exchanged in advance.
>
> >This is not a criticism but the reality is that not everybody seems to
> >want that to happen for reasons that are not clear and since we live
> >in a democracy they are entitled to act the way they want within the
> >law.  It is useful therefore to rationalise the status quo and see
> >where we are working with regard to the overall analysis of the
> >industry from a scientific point of view.  
> >If anybody wants to pursue
> >practically unbreakable (less than perfectly unbreakable cryptography)
> >as a selfish cultural pursuit say, then so be it but it needs to be
>
> Less than perfectly unbreakable cryptography is a reasonable engineering
> choice for many applications (actually almost all of them, given the
> limitations of perfectly unbreakable cryptography).  
>
> >made clear to new readers that this something less than the more
> >serious end-point of perfect secrecy of communications that is the
>
> Considering the number of discussions on what it takes to brute-force
> various ciphers, anyone who doesn't get that they don't provide
> perfectly unbreakable cryptography hasn't been paying attention.
>
> >only standard to be aimed at for main stream national and important
> >commercial levels.
>
> Perfect secrecy of communications is *NOT* the only standard to be
> aimed at.  For e-commerce with the general public, the goal is
> perfect secrecy of communications *that can be operated by stupid
> monkeys (stupid even compared to average pond scum)*, from computers
> likely to be infected with viruses and spyware, and with users who
> can easily be fooled into giving up their keys by sending them an
> email purportedly from Nigeria offering them imaginary huge piles
> of money.  Or they can be fooled into giving away passwords to
> anyone who calls themselves an administrator.  Hint:  that's
> unachievable.  One of the things you give up is perfect secrecy of
> communications when you know you can't keep the key secure anyway.
>
> >The peripheral secure communications of the present industry i.e. the
> >razzmatazz show case that includes news groups, dedicated associations
> >purporting to represent research, academies offering courses by
> >internal research team members, promoters of conferences worldwide, is
> >indeed an industry that is living off its defects instead of its
> >successes.  
>
> A news group is not an industry.  
>
> >A euphemism of “the emperor’s new clothes” is a quite apt
> >description – but the emperor is clearly stark naked and nobody
> >seemingly wants to give up his long-standing hobby of fantasy
> >cryptography by admitting to this.
>
> The industry offering perfect secure communications also has no
> clothes when it comes to admitting the need for a huge-bandwidth
> secure channel, vulnerability to getting out of sync, and a lot of
> administrative problems involving not re-using the same portion of
> the key more than once.  It's worse when adacrypt is denying that
> it is necessary to not re-use the same portion of the key more than
> once.
>
> >It is surely time to get real about the status quo.
>
> It is also time to get real about the enormous disadvantages of
> perfectly secure cryptography, like requiring a secure channel for
> key exchange which often isn't available or isn't secure.
>
> One of the really severe disadvantages of adacrypt's cryptography
> is that it is claimed to require a "keyboard operator", something
> unavailable on an e-commerce server.  This flaw is probably fixable
> without too much trouble.  Another problem is that, according to
> adacrypt, it only accepts subsets of the ASCII character set as
> plaintext while leaving out some of the most important ASCII
> characters, such as newline, tab, and carriage return.

Hi Gordon,

In my article "A New Approach to Cryptography" on http://www.adcrypt.com
I have acceded to the idea of retaining current ciphers albeit only
practically unbreakable cryptography unless it can be demonstrated
that it costs no more to replace them with my new unbreakable vector
cryptography.

I value your comments from a management perspective because frankly I
am not at all aut fait with that hands-on aspect of the industry - my
interest has been the intellectual challenge of the mathematical core
of the ciphers only and I sense that you are perhaps experienced in
the operation of crypto system infrastructures.

It is not a question of winning arguments here and I am sure you will
agree that it is pretty futile trying to discuss such a many-sided
thing as management by means of shuttle postings such as this when in
fact it warrants an expert workshop by management experts such as
yourself.

One thing sticks out however - if a secure communications problem is
resolved from being an erstwhile extreme piece of almost impossible
cryptography to one of management then it has come along way since
there is a huge availability of modern management know-how that is
available today in your industry in the face of a dearth of
unbreakable ciphers worldwide. I think youn are killing fleas but
letting the elephants run wild.

I am surprised that you take such a parochial view in some of the
points you have made.

I have given everthing you say much thought and I am satsified that
the claims I am making for my vector ciphers will stand up to expert
inspection easily and are not merely facile attempts at really
unbreakable cryptography.

An unbreakable algorithm is an absolute gem in any language - managing
it is not at all as difficult as you claim - I would welcome a
rigorous investigation by a team of experts - I think that is already
going on by several groups at the moment and has been for several
years judging from the regular daily visits to my website.

I will not comment on any particular point that you have made lest it
be a distraction but I can assure your that your are wide of the mark
in everything you claim as being deleterious to this cryptography.

They say necessity is the mother of invention - I strongly believe it
could happen very suddenly that advances in computer power could come
with such immediacy of effect on current brute force times as to make
it essential to governments to change immediately from current crypto
schemes.

My vector cryptography i.e the cryptography of three-dimensional space
is totally independent of computer power for all time - Cheers -
adacrypt
From: Gordon Burditt on 12 Jun 2010 16:26
>> �Another problem is that, according to
>> adacrypt, it only accepts subsets of the ASCII character set as
>> plaintext while leaving out some of the most important ASCII
>> characters, such as newline, tab, and carriage return.

>I value your comments from a management perspective because frankly I
>am not at all aut fait with that hands-on aspect of the industry - my
>interest has been the intellectual challenge of the mathematical core
>of the ciphers only and I sense that you are perhaps experienced in
>the operation of crypto system infrastructures.

I certainly DO know that a cryptosystem doesn't get to redefine
plaintext to something stupid, such as forbidding an end-of-line
character, and have much success at being adopted. Almost all of
the messages can't be encrypted. It's almost as bad as forbidding
vowels.

Did you really mean to say that your cryptography permits only
printable ASCII characters and no others? Especially no newlines
or tabs? Or was that a lie? If it was a lie, why are you throwing
your own cryptography under the bus?

>It is not a question of winning arguments here and I am sure you will
>agree that it is pretty futile trying to discuss such a many-sided
>thing as management by means of shuttle postings such as this when in
>fact it warrants an expert workshop by management experts such as
>yourself.

I take that as a concession that you have no idea how to answer the
criticisms.

The permitted character set for plaintext is not just a management
issue. *DOES* your cryptography forbid encryption of newlines, and
if so, *WHY*? Answer it here.

From: adacrypt on 13 Jun 2010 04:08
On Jun 12, 9:26 pm, gordonb.z5...(a)burditt.org (Gordon Burditt) wrote:
> >>  Another problem is that, according to
> >> adacrypt, it only accepts subsets of the ASCII character set as
> >> plaintext while leaving out some of the most important ASCII
> >> characters, such as newline, tab, and carriage return.
> >I value your comments from a management perspective because frankly I
> >am not at all aut fait with that hands-on aspect of the industry - my
> >interest has been the intellectual challenge of the mathematical core
> >of the ciphers only and I sense that you are perhaps experienced in
> >the operation of crypto system infrastructures.
>
Hi again,
> I certainly DO know that a cryptosystem doesn't get to redefine
> plaintext to something stupid, such as forbidding an end-of-line
> character, and have much success at being adopted.  Almost all of
> the messages can't be encrypted.  It's almost as bad as forbidding
> vowels.
>
> Did you really mean to say that your cryptography permits only
> printable ASCII characters and no others?  Especially no newlines
> or tabs?  Or was that a lie?  If it was a lie, why are you throwing
> your own cryptography under the bus?
>
> >It is not a question of winning arguments here and I am sure you will
> >agree that it is pretty futile trying to discuss such a many-sided
> >thing as management by means of shuttle postings such as this when in
> >fact it warrants an expert workshop by management experts such as
> >yourself.
>
> I take that as a concession that you have no idea how to answer the
> criticisms.

> The permitted character set for plaintext is not just a management
> issue.  *DOES* your cryptography forbid encryption of newlines, and
> if so, *WHY*?  Answer it here.

>own cryptography under the bus?


All modern programming language compilers have the built-in
attributes, New_Line, Set_Line_Length. End_of_Line, End_of_ File and a
host of others that may be called by a simple line of source code in
the program. There are aproximately 400+ of these attributes that are
rigorously tested before the ISO standard is granted to any language
compiler.

My cryptography is capable of encrypting all of ASCII (256 elements)
with great ease but that is totally unnecessary and indeed might cause
strange results at run time in a program that decrypts control
characters instead being safely limited to the writable subset
(elements 32 t0 126 incl) only.

In my cryptography the user types a file of plaintext externally in an
editor (that may be any editor apart from the Ada-95 editor in the
gnat 311.p complier package that comes with the compiler) or the user
may key in a message for encryption in real time interactive mode such
as say an email message for sending immediately or for sending later
on. The user does not need anything more than the writable subset of
ASCII to write any message complete with errors of any sort like
spacing, misspellings, and indeed misuse of any of the keyable
characters on a standard key board.

At run time the external file is read in character by character and
encrypted character by character exactlty as it was written i.e.
complete with mistakes if any. In interacrtive mode the characters
are encrypted between key strokes as they are keyed in and the
ciphertext is filed for electronic transmission.

It is ridiculous for you to talk about the user controlling line
length, tabulation etc from the keyboard when the program is already
doing it.

You must not be programmer either as well as not being a
cryptographer ?

Just thought I would tell you this just and not let you go on spouting
ignorance. - Cheers adacrypt
From: rossum on 13 Jun 2010 12:32
On Sat, 12 Jun 2010 15:26:46 -0500, gordonb.z5qbm(a)burditt.org (Gordon
Burditt) wrote:

>I certainly DO know that a cryptosystem doesn't get to redefine
>plaintext to something stupid, such as forbidding an end-of-line
>character, and have much success at being adopted. Almost all of
>the messages can't be encrypted. It's almost as bad as forbidding
>vowels.
Just for that I have decided to disemvowel your message:

crtnly D knw tht cryptsystm dsn't gt t rdfn
plntxt t smthng stpd, sch s frbddng n nd-f-ln
chrctr, nd hv mch sccss t bng dptd. lmst ll f
th mssgs cn't b ncryptd. t's lmst s bd s frbddng
vwls.

:)

rossum
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: The Winds of Change - The Three Faces of Cryptography.
Next: General factoring result for k^m = q mod N