An Honest and Simple Question.
in [Cryptography]
|
From: Mark Murray on 16 Jul 2010 06:06 On 07/16/10 07:03, adacrypt wrote: > To me this seems the obvious thing to do. I can�t understand why I am > being admonished to read bytes instead of plaintext as it appears. You are being asked not to make a distinction between "bytes" and "plaintext", as real cryptography is content-agnostic. The "bytes" _are_ the "plaintext" (and /vice versa/). The resultant "ciphertext" is also "bytes". M --
From: Mok-Kong Shen on 16 Jul 2010 06:05 adacrypt wrote: > What I want to know is the mechanics of the external interface with > the human operator - does that person key in the data directly to the > keyboard (please take it that only security of information is being > considered here) in all cases. If so is this the norm for most general > cases - thanks again - adacrypt Thomas has told you that the source can be of widely different nature. So the 'norm' and the 'most general cases' can vary also, dependent on the kind of applications. If what is to be encrypted is e.g. pictures, then the files can stem directly from digital cameras and there is practically no keying on the keyboard except for the commands of the operating system. Text documents may be scanned, etc. etc. A modern crypto software should thus be able to process an arbitrary user-given bit sequence. BTW, in another thread of yours I mentioned that you should 'once' spend some effort to explain your encryption scheme concretely and concisely and in terms that are readily to be understood by many so that it could be thoroughly examined and discussed. You seemed to dislike that and instead attempted to ask some 'peripheral' (with respect to your scheme) questions in a number of threads, IMHO. M. K. Shen
From: Tom St Denis on 16 Jul 2010 07:47 On Jul 16, 4:55 am, adacrypt <austin.oby...(a)hotmail.com> wrote: > That's fine for what happens internally as called for by the cipher > program algorithm. > What I want to know is the mechanics of the external interface with > the human operator - does that person key in the data directly to the > keyboard (please take it that only security of information is being > considered here) in all cases. If so is this the norm for most general > cases - thanks again - adacrypt So what we have here is the author of revolutionary cryptography that will change the world who doesn't know how computers work and thinks that people actually type by hand their symmetric keys into ciphers. Tom
From: Paulo Marques on 16 Jul 2010 10:46 Tom St Denis wrote: > On Jul 16, 4:55 am, adacrypt <austin.oby...(a)hotmail.com> wrote: >> That's fine for what happens internally as called for by the cipher >> program algorithm. >> What I want to know is the mechanics of the external interface with >> the human operator - does that person key in the data directly to the >> keyboard (please take it that only security of information is being >> considered here) in all cases. If so is this the norm for most general >> cases - thanks again - adacrypt > > So what we have here is the author of revolutionary cryptography that > will change the world who doesn't know how computers work and thinks > that people actually type by hand their symmetric keys into ciphers. My vote is for no discharge for this patient either ;) -- Paulo Marques - www.grupopie.com "There cannot be a crisis today; my schedule is already full."
From: Gordon Burditt on 16 Jul 2010 11:28
>My question is this: How in general, in modern Western cryptography >is textual data for encryption entered into a computer. Is it keyed >in interactively at the keyboard or is it read in from prepared >external batch files. I am speaking of ordinary plaintext from the >character set of printable ASCII. I do not enter ordinary plaintext (whether it's for encryption or not) from the character set of printable ASCII. Even one line of plaintext ends in a newline. If it's anything complicated (even one line can be complicated), and it's not already machine-readable, I'm going to be typing it into a text editor. (That text editor may be creating files on an encrypted filesystem. Or maybe the message only needs encryption for sending over the Internet via email.) In pretty much all cases of text files, it is important that the newlines stay where they are. Failure to do this can render source code unusable, and make poetry unreadable. It makes CSV files unusable. In no case is it acceptable to limit line lengths by inserting a newline in the middle of a word. Stuff that I encrypt is generally not so sensitive that I can't keep it available unencrypted to work on it. (Why keep around secret stuff if you can't use it for something?) It may be stored on an encrypted file system, but when it's mounted, I can access it transparently without having to deal with the encryption at that point. Unmount the encrypted file system, and it can't be accessed without the passphrase. The threat is more of an email going astray or getting intercepted over the Internet, or perhaps a lost or stolen laptop, than someone using my computer when I turn away from the computer to talk to someone else with the encrypted filesystem mounted. The data is generally stored in a file in a form so I can *USE* it, whether that is a text file, a word processing file, a spreadsheet, an image, or whatever. You may think of those as "batch files" for encryption, but I'm more concerned with being able to *use* the files, and these are file types appropriate to the application. If I send someone an encrypted email, it's probably important enough that I keep a copy, at least until I'm sure he got it and answers. >My own ciphers are designed to 1) handle large-volume secure >communications by reading plaintext in from external batch files and >writing out the ciphertext that emanates from the encryption to >another dedicated external file that may then be transmitted by >electronic means and 2) short impromptu email messages are keyed in >from the keyboard in interactive mode, encrypted, and the ciphertext >is then written to an external file for transmission by electronic >means. It's unlikely I'm going to use (2) much at all. If it's used often enough, I'll have a script that brings up a text editor, then encrypts and sends the message when it is done. Your ciphers (you claim) are theoretically unbreakable but they are theoretically unbreakable *EVEN WITH THE KEY*, since they mangle plaintext irretrievably. >To me this seems the obvious thing to do. I can�t understand why I am >being admonished to read bytes instead of plaintext as it appears. > >Surely it would be retrogressive to prepare plaintext as bytes instead It is unnecessary to "prepare plaintext as bytes". It already *is* bytes. If ADA can't do this (and it *can* do this, but you don't seem to know enough ADA to figure out how), dump ADA. You don't seriously think someone is suggesting that you to "prepare" a file filled with ASCII 1's and 0's in groups of 8, do you? I've got programs on my computer that can encrypt an arbitrary file in one of many ciphers, then decrypt it back and get exactly the same file contents as the original. Why can't yours do the same thing? >of just letting the computer do that. Don't you get it? I don't have to "prepare a batch file", an application file is already there. I have a spreadsheet with an inventory of the computers on the network. It gets updated often as things change. If the boss wants a new copy, I send it as an attachment to an email. No, it's generally NOT needed to do an "export to ASCII", and in any case, messing up the newlines in an export will mangle the data when it's imported. The file gets run through encryption, then base64 to give a palatable character set for email, and made into an attachment. >What gives here? - adacrypt You don't understand how people use computers. Perhaps your brain is theoretically impenetrable by common sense. You've designed cryptography that can only encrypt and decrypt a near-empty subset of documents used today. |