The Winds of Change - The Three Snake Oils of Cryptography.
in [Cryptography]
|
Prev: The Winds of Change - The Three Faces of Cryptography.
Next: General factoring result for k^m = q mod N
From: rossum on 13 Jun 2010 12:42 On Sun, 13 Jun 2010 01:08:55 -0700 (PDT), adacrypt <austin.obyrne(a)hotmail.com> wrote: >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. How is the relevant? Your users will be encrypting text files, data files, image files, spreadsheets, compressed files etc. >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. So, you cannot handle Newline, you cannot handle Return, you cannot handle Tab since they are all outside the range you specify. You NEED to redesign/rewrite your software so it handles the full range of bytes from 00 to FF. > >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. Tab is keyable on a standard keyboard. Many characters, such as § are keyable on a normal keyboard. On mine it is Alt+Numeric Keypad to get at the characters above ~. > >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. Nope. You just said that you cannot deal with Tab characters and a user may want to type in Tab characters, eg at the start of paragraphs. rossum > 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: adacrypt on 13 Jun 2010 14:30 On Jun 13, 5:42 pm, rossum <rossu...(a)coldmail.com> wrote: > On Sun, 13 Jun 2010 01:08:55 -0700 (PDT), adacrypt > > > > > > <austin.oby...(a)hotmail.com> wrote: > >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. > > How is the relevant? Your users will be encrypting text files, data > files, image files, spreadsheets, compressed files etc. > > >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. > > So, you cannot handle Newline, you cannot handle Return, you cannot > handle Tab since they are all outside the range you specify. > > You NEED to redesign/rewrite your software so it handles the full > range of bytes from 00 to FF. > > > > >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. > > Tab is keyable on a standard keyboard. Many characters, such as § are > keyable on a normal keyboard. On mine it is Alt+Numeric Keypad to get > at the characters above ~. > > > > >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. > > Nope. You just said that you cannot deal with Tab characters and a > user may want to type in Tab characters, eg at the start of > paragraphs. > > rossum > > > > > 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- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - Hi rossum, Thus far I have only concerned myself with the encryption of information per se in say normal security of information exchanges - I can easily encrypt anything from 00 to FF - there is now problem with anything in vector cryptography - I dont even have to use ASCII if I wish - I can always use a customised enumeration type of any size greater than ASCII to represent anything I wish - like music, smells. tastes -anything you care to mention - there are no limitations whatever to what vector cryptography can do - Cheers - adacrypt
From: Gordon Burditt on 13 Jun 2010 22:39 >> 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? >> 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. > >All modern programming language compilers have the built-in I suspect by that you mean "ADA, and nothing else", or "my particular ADA compiler, and nothing else".. >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. What program? I'm talking about *TEXT FILES*, which, unless they are also program source code, will go nowhere near a compiler. >There are aproximately 400+ of these attributes that are >rigorously tested before the ISO standard is granted to any language >compiler. That's funny, there's no sign of those in the C standard. >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 We're not talking about *a program*, we're talking about *your decryption program*. >characters instead being safely limited to the writable subset >(elements 32 t0 126 incl) only. You do know that it is possible to have the input character set != the output character set, don't you? It's what things like uuencode, base-64, and MIME encoding are for. >In my cryptography the user types That's a problem right there: if it's worthwhile information, it's already available in a file, such as a saved email file or USENET message. Users shouldn't have to retype it. And users shouldn't be limited to only characters present on a keyboard. >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. You need to understand that including newline, carriage return, and tab in a text file is not misuse or a mistake, it's a primary requirement. C source code must contain newlines. Remove them and it won't compile. A lot of assembly-language source files have one statement per line. Lots of UNIX administrative files and shell scripts do also. Remove the newlines and you have an unusable mess. >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. What program? We're talking about messages and data files. WOW! Talk about not understanding the market for your cryptography! >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: Noob on 14 Jun 2010 03:39 rossum wrote: > 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. I think most consider the English 'y' to be a vowel. http://en.wikipedia.org/wiki/Vowel#Written_vowels
From: rossum on 14 Jun 2010 08:58
On Mon, 14 Jun 2010 09:39:41 +0200, Noob <root(a)127.0.0.1> wrote: >rossum wrote: > >> 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. > >I think most consider the English 'y' to be a vowel. > >http://en.wikipedia.org/wiki/Vowel#Written_vowels I am, at least in part, Scottish not English. :) rossum |