Prev: Primesums Patterns , the frame of the last four top planes and their the three interior zones in a 2D pix!
Next: Call for papers (Deadline Extended): ISP-10, USA, July 2010
From: adacrypt on 26 Mar 2010 05:36

I find myself at odds with a lot of the generally entrenched ideas
being verbalized by some readers and I would like very much to clear
the air for my own benefit as follows.

In my view the interface between humans wanting to communicate in
secrecy by means of computer encrypted data is threefold, there’s the
fundamentally important ASCII to begin with, then the standard
keyboard common to all computers (in the west at least) which is
comprised of the 95 writable alphanumeric characters of ASCII and some
control characters that don’t concern me in this discussion, and
finally the programming languages that are designed around ASCII.

Whatever your choice of programming language may be, they all use
ASCII (the west may be assumed everywhere here in these notes and in
this context) and they each interact with ASCII through similar
means. They each treat the 95 strong alphanumeric set as an
enumeration ‘type’ and all use similar names for two very important
attributes that enable them to read and write directly to this
essential foundation set. For instance in the Ada programming
language the attribute ‘POS means the position in the set of some
character in question which might be for instance upper-case P, which
is 80. The other attribute is ‘VAL which is the converse of ‘POS
means that ‘VAL 80 = P, it is ditto for all the other characters in
the set which goes from 32 to 126 inclusively i.e. 95 alphanumeric
characters in the positive integer range 32 to 126. It can be seen
that the language makes provision for rapid, direct to-ing and fro-ing
to arrays and other data structures within the scource-code as indeed
does also all the other programming languages that are available today
in computer science.

Note well, this is decimal representation. It enables direct
inversion of the set of integers to the set of characters as an
inbuilt property that resides permanently in the library of each
language. It is a programming standard that is not negotiable. It is
not an option to design source-code that uses some other number base
because the attributes like ‘POS and ‘Val in the source-code just will
not work that way (binary inputs will work but look at the extra
keying work required and is not standard programming behaviour.)

So, the design number-base in computer-programmed encryption work is
decimal – not binary.

When plaintext is transformed into cipher text it is the remit of the
cryptographer to concentrate on making this theoretically unbreakable
to any adversary. They should be free and unencumbered to focus on
this task alone and entirely.

Whatever form the cipher text may take in open view on the table
before Alice, Bob and Eve, it will eventually be transported on the
ether by electronic means as bytes of machine code just like all other
email but this is of no interest to them (for discussion purposes
here) because it is the task of a different expert (for the time
being) to optimize that separate operation . There are millions of
this latter expert type around and millions more of experts in
infrastructure management but no cryptographers capable of doing the
vitally important work of unbreakable encryption are available – none
whatever that we know of.

What I am saying here is that it is counter-productive to mix the
jerseys i.e putting constraints on cryptographers to extend themselves
so as to facilitate the eventual email transmission instead of being
free to keeping their eye on the crypto ball only, that alone is
demanding and problematic enough for design cryptographers. Liaison
with the other external manager types should be on separate
uncompromising ground at a different time and place.

What I am also saying is that binary representation of ASCII should
not have been used ever in cryptography – it is non-standard in source
code and its only place is inside the CPU of the computer only?

The Mistake.

It was a hugely simplistic piece of gimmickry by the US government to
model ASCII as bytes of binary digits ever. That is fine for
descriptive documentation and it is a happy coincidence that there is
a binary byte for every element of ASCII. It should have stopped
there however and taking it into cryptography (AES and Xoring the
historic OTP?) was shortsighted. Effectively that was a move down the
wrong road. Binary based cryptography has run out of road now but the
damage has been done, many crypto minds are so addicted to binary
operation that they must firstly project all alternative schemes in
any type of diverse data into something equivalent of the binary-based
operation that they are familiar with – otherwise there is a huge
mental block that they cannot see as simply being a boulder in the
middle of the trail.

Recent _Posts

I have been promoting something called ASCII_Modulated_Vigenere
cryptography recently and am confounded by some of the questions
readers are asking.

1)I referred to p.15 in “Applied Cryptography” by Bruce Schneier that
states the equation of a Vigenere square as a mathematical equation.
Please note this was just a flag that points to the fact that the idea
has been mooted before now (happily by Mr. Schneier) , it ends there
completely however. There is nothing more in Bruce Schneier ‘s book
that is relevant and asking me why I didn’t turn the page to the next
page, p.16 and read irrelevant text there just doesn’t make sense. I
am making the point that all of the binary-intensive theory that MR.
Scheier expounds is the rest of that chapter is totally misplaced and
is inapplicable in the cryptography that I am promoting. My Vigenere
cryptography is decimal-based and the entities use mutual database
technology that requires single iconic data inputs (character by
character) for best operation. Alphanumeric data in and transformed
alphanumeric data out is the order of the day – binary data is
unthinkable and is obviously non-standard anyway in the programming
context of this crypto scheme.

2)The Square that is at the core of the Vigenere Ciphers that I am
promoting is populated by the 95 strong writable subset of ASCII as
described which means a square that has 95^2 elements. It was asked
why I don’t go for the whole of ASCII and create a square that has 255
elements along each side i.e 255^2 all told elements. The reason for
this is that the ‘information interchange’ part of ASCII is provided
by the writable subset only and the programming languages won’t accept
anything else at decryption time without a lot of trouble (if at all).

3)Somebody said that the industry has moved on from ASCII to Unicode
and I should move on with it. I have been studying Unicode for years
and have written reams of text on the subject. I am convinced that
including ASCII in Unicode is a polite token in practice that had to
be done by the Unicode Consortium but in reality ASCII is going to be
around forever (in western commerce at least).

Question:
Example query:
I believe that every single element of my alphanumeric cipher text
goes out on the superhighway as a single byte of machine code in the
transmission technology of the internet. If I changed that same
element into a binary representation of the cipher text element it
would require a separate single byte of machine code for every single
binary digit of the new cipher text form and would then require 8
bytes of machine code that obviously means a large cipher text
expansion? True or False?– what gives here ?

Discussion:
I believe that the party is over for binary representation of data
within cryptography and has a place only in academic computer
science. I believe it was a mistake first day that is now coming home
to roost to the detriment of any future real progress in cryptography.

This is not meant to be any kind of aggressive attack i.e rattling
cages just for the hell of it – I am grateful for peoples’ remarks to
date and I value your comments – please don’t spare the full expansion
of any points you are making. The only value in my view of binary
numbers is in modeling machine code in academia. I find it irritating
that everybody is so hooked on it that they seem hypnothised by the
fact.

I think it is quite wrong to think that binary cipher text is looked
on as virtually prepared machine code and is highly cost effective
because of that – What happens in practice ? anybody – thanks in
anticipation - adacrypt
From: Mark Murray on 26 Mar 2010 16:01
On 26/03/2010 09:36, adacrypt wrote:
>
> I find myself at odds with a lot of the generally entrenched ideas
> being verbalized by some readers and I would like very much to clear
> the air for my own benefit as follows.

You might ant to consider your own entrenched ideas.

> In my view the interface between humans wanting to communicate in
> secrecy by means of computer encrypted data is threefold, there�s the
> fundamentally important ASCII to begin with, then the standard
> keyboard common to all computers (in the west at least) which is
> comprised of the 95 writable alphanumeric characters of ASCII and some
> control characters that don�t concern me in this discussion, and
> finally the programming languages that are designed around ASCII.

1) ASCII is not "fundamentally important".

2) There is noting magic about a keyboard layout.

3) Programming languages are not designed around ASCII.

Now start again. Your message is numbers. That's all. All ASCII is,
is a convention. Pretend your message is (say) a JPEG photograph or
an MP3 soundbite. Just numbers.

M
--
Mark "No Nickname" Murray
Notable nebbish, extreme generalist.
From: WTShaw on 26 Mar 2010 16:45
There is much good in what you say and I respect the weights of your
arguments. There are a couple of areas, not much, where you are not
quite there, but remember that I agree with most of your conclusions.
The kicker is the two comments that follow your statement make some of
the same bad mistakes that you complain about.

I do need to explain that my own work has included much of what you do
or want to do, with a few differences of course.

Details perhaps later...

From: adacrypt on 27 Mar 2010 09:59
On Mar 26, 8:45 pm, WTShaw <lure...(a)gmail.com> wrote:
> There is much good in what you say and I respect the weights of your
> arguments.  There are a couple of areas, not much, where you are not
> quite there, but remember that I agree with most of your conclusions.
> The kicker is the two comments that follow your statement make some of
> the same bad  mistakes that you complain about.
>
> I do need to explain that my own work has included much of what you do
> or want to do, with a few differences of course.
>
> Details perhaps later...

Hi WT,

I know you are doing a lot more with ASCII than I am. I am quite
happy to settle with the writable subset once I know that the general
concept is working in your broader designs - no need for me to pursue
it when your'e doing it. I think resurrecting the Vigenere Cipher is
a good idea in principle.

Digressing.

I was quite startled to find how easily the Vigenere cipher can be
adapted to the simple quadratic - using ax^2 + bx + c, I'm saying put
the plaintext as one root and the key as the other and then work on a,
b, c in the discriminant (b^2 + 4ac to generate ciphertext with a
random key composed of multiple modules of the ASCII subset of 95
alphanumeric keys.- Could you try this sometime?

Digressing again.

I found that when using Ada, the end-of -file is flagged by one of
the control keys' value (I think but haven't proved) - I found that I
could encrypt files of plaintext no bother but decrypting was
sometimes terminated prematurely when using the full ASCII set - I
didn't bother investigating why and what I'm saying is pure conjecture
- maybe it applies to Ada - maybe I am quite wrong altogether.

Digressing once more.

Modus operandi regarding randomness - bear with me - this is intended
as general info for other readers'

I use two random keys.

One key is simply a huge set of non-repeating positive integers often
generated as a functional fallout in some algorithmic process.

The other random key is formed from round modules of the 95 ASCII
subset (95 x n) where n is geared to equate with the message length -
padding is nearly always required.

The second random key is inevitably a subset of the large set of non-
repeating positive integers (described) that also equates with the
message length.- see the lemma in this respect.

* Important Lemma.

Any subset of a larger single non-repeating set is itself also
random.

Both of these random key sets are usable either on their own or in
tandem.

Cheers - adacrypt - after the revolution !
From: adacrypt on 27 Mar 2010 10:41
On Mar 26, 8:45 pm, WTShaw <lure...(a)gmail.com> wrote:
> There is much good in what you say and I respect the weights of your
> arguments.  There are a couple of areas, not much, where you are not
> quite there, but remember that I agree with most of your conclusions.
> The kicker is the two comments that follow your statement make some of
> the same bad  mistakes that you complain about.
>
> I do need to explain that my own work has included much of what you do
> or want to do, with a few differences of course.
>
> Details perhaps later...

Another Thing.

I don't think its feasible for western keyboard operators ( I envisage
these to be nothing more than good ordinary non-specialist office
workers) to be given large tracts of foreign plaintext for keying in
to an embedded crypto sysytem. I believe the interface between the
keyboard operator and any foreign language should be a string of hex
that represents the plaintext file - this has to be prepared by a
language-orientated intermediary.

Then,

(In the West). An ASCII-based cipher such as we are both working on
should be used as a secure surrogate means of encrypting all other
languages in Unicode.

To explain what I mean, the set of plaintext that represents the
particular interface is treated simply as a plaintext file of
hexadecimal digits and encrypted as such - i.e. a set of aphanumeric
characters from a 16-element alphabet that are in truth hex digits
but are being treated as lexical words of characters for the time
being.

The implications are enormous - one ASCII-based crypto system in the
west is usable on all Unicode - while being an element of Unicode
itself to all other countries - each country repeats the same ploy but
in its own information interchange system i.e. it uses its own set of
code points as a secure surrogate sytem when communicating to other
countries - plaintext per se is never used and key boards remain
unchanged.

- Austin O' Byrne
 |  Next  |  Last
Pages: 1 2 3
Prev: Primesums Patterns , the frame of the last four top planes and their the three interior zones in a 2D pix!
Next: Call for papers (Deadline Extended): ISP-10, USA, July 2010