Binary Application Ciphers an Anomaly - Help Me Get it Right.
in [Cryptography]
|
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: Gordon Burditt on 28 Mar 2010 02:10 >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, It's important to have a character set, and it's important for it to be standardized. Nowadays, I don't think that character set is ASCII, though. >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 What is a "writable character"? I can type a lot more than 95 characters on a standard keyboard. There are not 95 alphanumeric characters in ASCII. There are 62. (lower case alphabetic, upper case alphabetic, and digits.) The other 33 are not alphanumeric, and are mostly punctuation and symbols. >control characters that don�t concern me in this discussion, and If you are so concerned about only using ASCII, why is there a character with hex value 0x92 between the don and the t in the line above from your post? If you intend communicating in text, it's important that there is a character to represent a new line. It's probably more important than one of the lesser-important vowels. You do not get to re-define plaintext, which incidentally often includes images, executable computer programs, sound, and other stuff not normally represented in ASCII, along with lines of ASCII separated by newline characters. >finally the programming languages that are designed around ASCII. You can't represent C source without a character for newline. I doubt you can represent ADA source without a character for newline, either. >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. A C or C++ implementation does not necessarily use ASCII: the character set is left unspecified, and EBCDIC is allowed as a choice. With a little care, and use of character constants like 'P', it is possible to write a C program that does not *care* about the character set (as long as it has a certain base set of characters) and works equally well with ASCII and EBCDIC. >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. In C and C++ a character is not converted to and from an integer type, it *is* an integer type, and those attributes you refer to are unnecessary. And they certainly don't have names that are spelled the same as they are in ADA. >For instance in the Ada programming >language the attribute �POS means the position in the set of some Why are you using the non-ASCII character with a value of 0x91 before the letters POS in the line above from your post? Is that character actually necessary in ADA source in order to use the attribute? >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 Why are you using the non-ASCII character with a value of 0x91 before the letters POS and VAL in the line above from your post? Does ADA really require that non-ASCII character? >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. Only if you choose to use decimal representation when outputting the number for humans to read or when humans write programs. The number in an integer variable is a value; it doesn't *have* a base until you decide to put it in human-readable character form. >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.) Does VAL return the value eighty or does it return the character eight followed by the character zero? It should return something (in ADA) that compares equal to 80 and equally well compares equal to 16#50# . C allows for octal, hexadecimal, and decimal numeric constants. So does ADA. In fact, ADA will let you have numeric constants for any base from 2 to 16, inclusive. You can use any number base you want for input and output from the program, even if the programming language does not have it built-in. >So, the design number-base in computer-programmed encryption work is >decimal � not binary. Incorrect. Values of variables do not have a base. Input and output of values in the form of character strings for humans to read can be done in whatever base the programmer and/or language is willing to deal with. >When plaintext is transformed into cipher text it is the remit of the >cryptographer to concentrate on making this theoretically unbreakable >to any adversary. Incorrect. Making a cipher system theoretically unbreakable requires too much headache in the way of secure channels for keying material for some designs, so, it is exactly the WRONG thing to do in some situations. One of the communication partners often can't use it. One example for where it is exactly the wrong thing to do is in SSL for secure web sites. Many of their customers are talking with that site for the first time, do not have *any* secure channels, and consider all that stuff entirely too much trouble. Public-key cryptography works much better here. >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 "machine code" refers to code *executed* by a CPU. I hope you don't think that's what email consists of. >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 Why are you using the non-ASCII character with the value 0x96 in the line above after the word "available"? >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 Fine, so design an encryption algorithm that can encrypt *ANYTHING* representable as bytes: ASCII text (including newlines), UTF-8 text (including newlines), Unicode text (including newlines), compressed text, images, sounds, computer programs, etc. >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? For many types of encryption, (such as the XOR operation with a key stream) it is not necessary to represent codes for the plaintext in the source code. >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. No, it's not a happy coincidence. ASCII translates characters to and from *numbers* (not decimal numbers, just *numbers*). For every number there is a binary representation for it. And if ASCII didn't fit in 8-bit bytes, I'm sure we wouldn't *have* 8-bit bytes, we'd have something larger that character codes did fit in. >It should have stopped >there however and taking it into cryptography (AES and Xoring the >historic OTP?) was shortsighted. Why? Just because you think it was in the wrong base? >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. It's *NOT* an ASCII character set if it doesn't have a newline character in it. >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 Only to someone who doesn't think. You don't even seem to know what binary data *IS*. It's *NOT* sets of 8 bytes of '0' or '1' for each character. >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 Incorrect. Line boundaries convey meaning in plaintext. >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 What's sent on the net is not normally "machine code", which is something to be executed as an instruction by a CPU. What's sent is a single byte, not of machine code, but of data. >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 ? If you don't understand this, you shouldn't be trying to rant about binary vs. decimal. Only if you program it stupidly. You could also send the ASCII character string "one hundred and twenty-two" instead of a single byte with the value 0x7a to send a ciphertext 'z'. >Discussion: >I believe that the party is over for binary representation of data >within cryptography and has a place only in academic computer >science. You're delerious. >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. Any number can be represented in any base you want, and with modern CPUs conversion is so fast you don't need to worry about it (especially compared to the time required to read/write it from disk or transmit it over the net). >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 Cipher text is not *any* type of "machine code" (it is just data) - think of the viruses an adversary could introduce into your system if ciphertext was actually executed as a program.
From: Gordon Burditt on 28 Mar 2010 02:54 >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. You shouldn't be keying in foreign plaintext to an embedded crypto system. You should already have that data in machine-readable form before you decided to send it to someone else. If it's a document, it should be in electronic form already before you need to send it to the home office. >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. What happened to your fixation on decimal? If it has to be typed, why shouldn't it be TYPED by a language-oriented intermediary? (and using something better than a hexadecimal-only keyboard) If the language only extends ASCII by a few accented letters (say, Western European languages like French), then it's probably easy to train someone to type those accented letters and give them a better keyboard. Openoffice allows me to "type" special characters with a pull-down menu to select one with a mouse, even with an ordinary US keyboard. My guess is that Microsoft Office allows the same thing. Let the computer figure out what the UTF-8 code is. You could also have a document with the special characters relevant to a language, then cut-and-paste them as necessary. Or perhaps a lot of the accented letters could be inserted via spell-check. If it's something much different, like, say, Chinese, Japanese, or Farsi, you'll need someone who can read the language. And perhaps a special keyboard. Did you know that with a standard US keyboard you can type every character code between 0 and 255, inclusive? It may not be intuitive or fast without a character chart, but it can be done. >(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. Why not an 8-bit-byte-based cipher? >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. What's wrong with the set of plaintext that represents the particular interface is treated simply as a plaintext file of 8-bit bytes and encrypted as such - i.e. a set of bytes from a 256-element alphabet that are in truth bytes of UTF-8 multibyte characters but are being treated as lexical bytes of characters for the time being. All those files of ASCII characters don't have to be changed. >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. You do not get to redefine plaintext. You also have to assume that at some point an encrypted document gets turned into plaintext and is actually *USED* for something, just like the non-secret stuff, so you want it in electronic form.
From: adacrypt on 28 Mar 2010 03:36 On Mar 28, 7:54 am, gordonb.za...(a)burditt.org (Gordon Burditt) wrote: > >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. > > You shouldn't be keying in foreign plaintext to an embedded crypto > system. You should already have that data in machine-readable form > before you decided to send it to someone else. If it's a document, > it should be in electronic form already before you need to send > it to the home office. > > >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. > > What happened to your fixation on decimal? > > If it has to be typed, why shouldn't it be TYPED by a language-oriented > intermediary? (and using something better than a hexadecimal-only > keyboard) If the language only extends ASCII by a few accented > letters (say, Western European languages like French), then it's > probably easy to train someone to type those accented letters and > give them a better keyboard. Openoffice allows me to "type" special > characters with a pull-down menu to select one with a mouse, even > with an ordinary US keyboard. My guess is that Microsoft Office > allows the same thing. Let the computer figure out what the UTF-8 > code is. You could also have a document with the special characters > relevant to a language, then cut-and-paste them as necessary. Or > perhaps a lot of the accented letters could be inserted via > spell-check. > > If it's something much different, like, say, Chinese, Japanese, or > Farsi, you'll need someone who can read the language. And perhaps > a special keyboard. Did you know that with a standard US keyboard > you can type every character code between 0 and 255, inclusive? It > may not be intuitive or fast without a character chart, but it can > be done. > > >(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. > > Why not an 8-bit-byte-based cipher? > > >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. > > What's wrong with the set of plaintext that represents the particular > interface is treated simply as a plaintext file of 8-bit bytes and > encrypted as such - i.e. a set of bytes from a 256-element alphabet > that are in truth bytes of UTF-8 multibyte characters but are being > treated as lexical bytes of characters for the time being. All those > files of ASCII characters don't have to be changed. > > >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. > > You do not get to redefine plaintext. You also have to assume that at > some point an encrypted document gets turned into plaintext and > is actually *USED* for something, just like the non-secret stuff, so > you want it in electronic form. Hi, ASCII just happens to be a convenient ready-made enumeration type that comes with the Ada programming language as standard in the Ada reference Manual. It is also the national standard in America. I can create a totally different enumeration type of any magnitude that will replace ASCII if I wish and the attributes 'Pos and 'Val will enable me to read and write to it as usual. I am not dependent on ASCII or indeed any standard. I can use it to encrypt pictures and music or indeed any other data very easily. It is possible to write a totally new package in this language to do almost anything - that includes a dedicated communications package containing an enumeration type for any other country that uses Unicode - it is a very powerful language - it is 'owned' by the US government These dedicated packages are very manageable behind the scenes in the infrastructure management sphere. - adacrypt - it is also saliently bug free which is ideal for secure communications. - adacrypt
From: Bruce Stephens on 28 Mar 2010 07:50 gordonb.jekdv(a)burditt.org (Gordon Burditt) writes: >>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, > > It's important to have a character set, and it's important for it > to be standardized. Nowadays, I don't think that character set is > ASCII, though. Ironically, his articles seem to be ISO-8859-1. [...]
From: Noob on 29 Mar 2010 05:49
Bruce Stephens wrote: > Ironically, his articles seem to be ISO-8859-1. From: adacrypt <austin.obyrne(a)hotmail.com> Newsgroups: sci.crypt Subject: Binary Application Ciphers an Anomaly - Help Me Get it Right. Date: Fri, 26 Mar 2010 02:36:58 -0700 (PDT) Organization: http://groups.google.com Lines: 155 Message-ID: <82a251c8-4ec2-4f42-ac34-a2f179d2fc97(a)k19g2000yqn.googlegroups.com> NNTP-Posting-Host: 86.183.113.103 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable => windows-1252 in quoted-printable ( http://en.wikipedia.org/wiki/Windows-1252 ) e.g. <quote original message> They each treat the 95 strong alphanumeric set as an enumeration =91type=92 and all use similar names </quote> Regards. |