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 14 Jun 2010 08:59 On Sun, 13 Jun 2010 11:30:25 -0700 (PDT), adacrypt <austin.obyrne(a)hotmail.com> wrote: >I >can easily encrypt anything from 00 to FF Then please amend your program so that it does so. rossum
From: adacrypt on 14 Jun 2010 10:36 On Jun 14, 1:59 pm, rossum <rossu...(a)coldmail.com> wrote: > On Sun, 13 Jun 2010 11:30:25 -0700 (PDT), adacrypt > > <austin.oby...(a)hotmail.com> wrote: > >I > >can easily encrypt anything from 00 to FF > > Then please amend your program so that it does so. > > rossum I have no intention of using all the bytes 00 to FF - I don't need to - anybody else who uses my ciphers does'nt need to either - The fact that you require this indicates a complete encryption anomoly on your part - you haven't read my last post - in any case my ciphers read in from either external batch files or from the interactive keyed in data at a keyboard - they evaluate the ASCII representation automatically - they never encounter any character outside of the writable subset of ASCII which is the intended design basis of the code by Uncle Sam - they will never read anything in bytes anyway since the programming language (complements of Uncle Sam again) use the denary representation of ASCII in the attributes of the enumeration data type that ASCII is - you are way off the mark in talking 00 to FF - Regards - adacrypt
From: Gordon Burditt on 14 Jun 2010 11:59 >> >I >> >can easily encrypt anything from 00 to FF >> >> Then please amend your program so that it does so. >> >> rossum > >I have no intention of using all the bytes 00 to FF - I don't need to >- anybody else who uses my ciphers does'nt need to either - The fact Nobody else uses your ciphers, except as a joke. Are you trying to say that no one ever wants to encrypt binary formats, which include audio, video, images, compressed data, executables, spreadsheets, Microsoft Word documents, emails, etc.? The people who make cable boxes and cell phones certainly disagree about not needing to encrypt audio and video. There are lots of programs that encrypt email. Telling a potential user of your cipher, when they ask for a feature, "don't want that, it's a mistake" is not a good way to get your cipher accepted. What does your encryption/decryption process, as you distribute it now, *DO* with a newline should it find one in a text file (say, ADA source code)? Yes, the ADA standard says ADA source code is made up of a sequence of lines, and although it does not specify how lines are represented, that's what lines are in ASCII. (a) the newline silently disappears in the encryption/decryption process. (b) the newline disappears in the encryption/decryption process, but a warning is given. (c) the newline is silently changed to a space. (d) the newline is changed to a space, but a warning is given. (e) the program aborts without encrypting or decrypting. (f) something else (what?) In case (a) and (b), ADA source code can be corrupted due to merging two keywords into one. The ADA standard allows ADA compilers to place a limit on the length of a line as low as 200 characters, so stripping out all the newlines of an ADA source file longer than 200 characters may run up against the ADA compiler limit, in cases (a), (b), (c), and (d). Yes, your favorite ADA compiler might take it, but it's no longer portable ADA source. >that you require this indicates a complete encryption anomoly on your What the heck is an "encryption anomoly", especially since you're talking about a *design requirement* for a cryptosystem? >part - you haven't read my last post - in any case my ciphers read in >from either external batch files or from the interactive keyed in data >at a keyboard - they evaluate the ASCII representation automatically - >they never encounter any character outside of the writable subset of >ASCII which is the intended design basis of the code by Uncle Sam - So when I put in a file with newlines in it, what happens to them when the message is decrypted on the other end? >they will never read anything in bytes anyway since the programming >language (complements of Uncle Sam again) use the denary >representation of ASCII in the attributes of the enumeration data type >that ASCII is - you are way off the mark in talking 00 to FF - Regards No, he's simply describing *DATA* in a way that has nothing to do with your favorite programming language. Your program is reading bytes because that's what the hardware does, and regardless of what *representation* it uses, it's still reading bytes. >- adacrypt
From: adacrypt on 14 Jun 2010 12:36 On Jun 14, 4:59 pm, gordonb.zx...(a)burditt.org (Gordon Burditt) wrote: > >> >I > >> >can easily encrypt anything from 00 to FF > > >> Then please amend your program so that it does so. > > >> rossum > > >I have no intention of using all the bytes 00 to FF - I don't need to > >- anybody else who uses my ciphers does'nt need to either - The fact > > Nobody else uses your ciphers, except as a joke. > > Are you trying to say that no one ever wants to encrypt binary > formats, which include audio, video, images, compressed data, > executables, spreadsheets, Microsoft Word documents, emails, etc.? > The people who make cable boxes and cell phones certainly disagree > about not needing to encrypt audio and video. There are lots of > programs that encrypt email. > > Telling a potential user of your cipher, when they ask for a feature, > "don't want that, it's a mistake" is not a good way to get your > cipher accepted. > > What does your encryption/decryption process, as you distribute it > now, *DO* with a newline should it find one in a text file (say, > ADA source code)? Yes, the ADA standard says ADA source code is > made up of a sequence of lines, and although it does not specify > how lines are represented, that's what lines are in ASCII. > > (a) the newline silently disappears in the encryption/decryption process. > (b) the newline disappears in the encryption/decryption process, but a > warning is given. > (c) the newline is silently changed to a space. > (d) the newline is changed to a space, but a warning is given. > (e) the program aborts without encrypting or decrypting. > (f) something else (what?) > > In case (a) and (b), ADA source code can be corrupted due to merging two > keywords into one. > > The ADA standard allows ADA compilers to place a limit on the length > of a line as low as 200 characters, so stripping out all the newlines > of an ADA source file longer than 200 characters may run up against > the ADA compiler limit, in cases (a), (b), (c), and (d). Yes, your > favorite ADA compiler might take it, but it's no longer portable > ADA source. > > >that you require this indicates a complete encryption anomoly on your > > What the heck is an "encryption anomoly", especially since you're > talking about a *design requirement* for a cryptosystem? > > >part - you haven't read my last post - in any case my ciphers read in > >from either external batch files or from the interactive keyed in data > >at a keyboard - they evaluate the ASCII representation automatically - > >they never encounter any character outside of the writable subset of > >ASCII which is the intended design basis of the code by Uncle Sam - > > So when I put in a file with newlines in it, what happens to them when > the message is decrypted on the other end? > > >they will never read anything in bytes anyway since the programming > >language (complements of Uncle Sam again) use the denary > >representation of ASCII in the attributes of the enumeration data type > >that ASCII is - you are way off the mark in talking 00 to FF - Regards > > No, he's simply describing *DATA* in a way that has nothing to do > with your favorite programming language. Your program is reading > bytes because that's what the hardware does, and regardless of what > *representation* it uses, it's still reading bytes. > > > > >- adacrypt- Hide quoted text - > > - Show quoted text - You are making very heavy going of something very straight forward - from memory I set a line terminator in my ciphers that are to hand by means of the Ada command line Set_Line_Length(77) - that happens to be one I use in one instance - The decryption program will terminate each line at 77 characters as it displays the messagetext which happens to suit my needs - a new line is automatic - the message text can be transferred into a Word document and re-editted as much as you wish - what's the prob ? I could do something much more sophisticated if I wanted but there is no need - I could even make it zero ! characters long if I wished. - adacrypt
From: adacrypt on 14 Jun 2010 13:04
On Jun 14, 5:36 pm, adacrypt <austin.oby...(a)hotmail.com> wrote: > On Jun 14, 4:59 pm, gordonb.zx...(a)burditt.org (Gordon Burditt) wrote: > > > > > > > >> >I > > >> >can easily encrypt anything from 00 to FF > > > >> Then please amend your program so that it does so. > > > >> rossum > > > >I have no intention of using all the bytes 00 to FF - I don't need to > > >- anybody else who uses my ciphers does'nt need to either - The fact > > > Nobody else uses your ciphers, except as a joke. > > > Are you trying to say that no one ever wants to encrypt binary > > formats, which include audio, video, images, compressed data, > > executables, spreadsheets, Microsoft Word documents, emails, etc.? > > The people who make cable boxes and cell phones certainly disagree > > about not needing to encrypt audio and video. There are lots of > > programs that encrypt email. > > > Telling a potential user of your cipher, when they ask for a feature, > > "don't want that, it's a mistake" is not a good way to get your > > cipher accepted. > > > What does your encryption/decryption process, as you distribute it > > now, *DO* with a newline should it find one in a text file (say, > > ADA source code)? Yes, the ADA standard says ADA source code is > > made up of a sequence of lines, and although it does not specify > > how lines are represented, that's what lines are in ASCII. > > > (a) the newline silently disappears in the encryption/decryption process. > > (b) the newline disappears in the encryption/decryption process, but a > > warning is given. > > (c) the newline is silently changed to a space. > > (d) the newline is changed to a space, but a warning is given. > > (e) the program aborts without encrypting or decrypting. > > (f) something else (what?) > > > In case (a) and (b), ADA source code can be corrupted due to merging two > > keywords into one. > > > The ADA standard allows ADA compilers to place a limit on the length > > of a line as low as 200 characters, so stripping out all the newlines > > of an ADA source file longer than 200 characters may run up against > > the ADA compiler limit, in cases (a), (b), (c), and (d). Yes, your > > favorite ADA compiler might take it, but it's no longer portable > > ADA source. > > > >that you require this indicates a complete encryption anomoly on your > > > What the heck is an "encryption anomoly", especially since you're > > talking about a *design requirement* for a cryptosystem? > > > >part - you haven't read my last post - in any case my ciphers read in > > >from either external batch files or from the interactive keyed in data > > >at a keyboard - they evaluate the ASCII representation automatically - > > >they never encounter any character outside of the writable subset of > > >ASCII which is the intended design basis of the code by Uncle Sam - > > > So when I put in a file with newlines in it, what happens to them when > > the message is decrypted on the other end? > > > >they will never read anything in bytes anyway since the programming > > >language (complements of Uncle Sam again) use the denary > > >representation of ASCII in the attributes of the enumeration data type > > >that ASCII is - you are way off the mark in talking 00 to FF - Regards > > > No, he's simply describing *DATA* in a way that has nothing to do > > with your favorite programming language. Your program is reading > > bytes because that's what the hardware does, and regardless of what > > *representation* it uses, it's still reading bytes. > > > >- adacrypt- Hide quoted text - > > > - Show quoted text - > > You are making very heavy going of something very straight forward - > from memory I set a line terminator in my ciphers that are to hand by > means of the Ada command line Set_Line_Length(77) - that happens to > be one I use in one instance - The decryption program will terminate > each line at 77 characters as it displays the messagetext which > happens to suit my needs - a new line is automatic - the message text > can be transferred into a Word document and re-editted as much as you > wish - what's the prob ? > > I could do something much more sophisticated if I wanted but there is > no need - I could even make it zero ! characters long if I wished. - > adacrypt- Hide quoted text - > > - Show quoted text - I had better make it clear that I am only interested in security of information - secure information interchange a la ASCII <=> code for information interchange - I am quite satisfied that I can secure any other form of data if I try but there is no need yet for that ? ? - my present ciphers are very speedy and easily managed - 15000 charcters per second on a home computer is ok for now at least - I guess I'll just stick with that for now - adacrypt |