An Honest and Simple Question.
in [Cryptography]
|
From: adacrypt on 16 Jul 2010 02:03 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. 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. To me this seems the obvious thing to do. I cant 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 of just letting the computer do that. What gives here? - adacrypt
From: unruh on 16 Jul 2010 02:49 On 2010-07-16, adacrypt <austin.obyrne(a)hotmail.com> wrote: > > 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 have designed a vehicle that is better than anything on the road. By the way, can you tell me, do people use steering wheels, or do they drag their free on the road to turn their cars these days?" > > 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. > > 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. And you think that the plaintext is represented inside the computer how? Baudet holes on a tape perhaps? > > Surely it would be retrogressive to prepare plaintext as bytes instead > of just letting the computer do that. > > What gives here? - adacrypt I don't know. What gives. > >
From: Thomas on 16 Jul 2010 04:35 >> 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. Well, you are wrong. Cryptography has not been exclusively designed to encrypt batch files and email messages. Cryptography is designed to encrypt anything that the user wishes to encrypt. Theoretically, a cipher takes a fixed quantity of bits in input and returns a the same quantity of bits in output. Who cares that it's ASCII plaintext ? Who cares it's Japanese characters ? For the cipher, it's just bits, and it's up to the computer to provide a mecanism to encode (not encrypt) the different types of information that works its way through your computer, into some quantity of bits, in a bijective mapping, so that potentially anything can be encrypted, and decrypted. What are the disadvantages of this method ? None. It is well-suited on current architectures, and can encrypt anything, as long as "anything" can be encoded and decoded correctly, which we know how to do efficiently. What are the disadvantages of your method ? It can only encrypt printable characters. Therefore your cipher is limited and potentially useless for .. uhm .. 98% of reasonable uses that could be made of it. As said before, you can't even encrypt a Word document nor a PDF. Even most pictures fail to encrypt. What if Chinese people want to communicate using your cipher, but in the same time they have a much wider alphabet than the one your cipher handles ? Hearing you, it seems computers are only capable of handling printable characters ... maybe you should download a hexadecimal editor and open some random files and see what is output ... Printable characters are a subset of ASCII, which is a method to encode readable plaintext into bits, and decoding bits into readable plaintext. Due to your poor information handling, your cipher is dreadfully limited to this tiny subset, which makes it unsuitable for any decent use. Therefore it is useless. And not because of the cryptography, juste because of how you handle information that the cipher has to encrypt. Here is the widely recognized method of how to handle information in a cryptographic application : 1. Decode the information into bits. This is done easily, for the computer everything is already bits. 2. Compress that information. There are algorithms for this. 3. Encrypt the resulting bitstream. 4. Encode the resulting bitstream into something suitable for its purpose. If the file is meant to stay on the computer, omit this step, otherwise - if it is meant to be sent by email for instance - encode it in some email-friendly encoding, for instance Base64 5. Transmit the resulting encoded information -- 6. Decode the information using the reverse process of the one used to encode it. 7. Decrypt the resulting bitstream. 8. Decompress the resulting bitstream. 9. Encode the information into something suitable for its purpose. For instance, if the decrypted information is meant to stay on the computer, just save it as a binary file. If the decrypted information is meant to be read quickly then ditched, encode it into the ASCII set for instance (or Unicode for a wider variety of characters, including asian characters).
From: adacrypt on 16 Jul 2010 04:55 On Jul 16, 9:35 am, Thomas <thomas.benet...(a)yahoo.fr> wrote: > >> 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. > > Well, you are wrong. Cryptography has not been exclusively designed to > encrypt batch files and email messages. Cryptography is designed to > encrypt anything that the user wishes to encrypt. Theoretically, a > cipher takes a fixed quantity of bits in input and returns a the same > quantity of bits in output. Who cares that it's ASCII plaintext ? Who > cares it's Japanese characters ? For the cipher, it's just bits, and > it's up to the computer to provide a mecanism to encode (not encrypt) > the different types of information that works its way through your > computer, into some quantity of bits, in a bijective mapping, so that > potentially anything can be encrypted, and decrypted. > > What are the disadvantages of this method ? None. It is well-suited on > current architectures, and can encrypt anything, as long as "anything" > can be encoded and decoded correctly, which we know how to do > efficiently. > What are the disadvantages of your method ? It can only encrypt > printable characters. Therefore your cipher is limited and potentially > useless for .. uhm .. 98% of reasonable uses that could be made of it. > As said before, you can't even encrypt a Word document nor a PDF. Even > most pictures fail to encrypt. What if Chinese people want to > communicate using your cipher, but in the same time they have a much > wider alphabet than the one your cipher handles ? > > Hearing you, it seems computers are only capable of handling printable > characters ... maybe you should download a hexadecimal editor and open > some random files and see what is output ... Printable characters are > a subset of ASCII, which is a method to encode readable plaintext into > bits, and decoding bits into readable plaintext. Due to your poor > information handling, your cipher is dreadfully limited to this tiny > subset, which makes it unsuitable for any decent use. Therefore it is > useless. And not because of the cryptography, juste because of how you > handle information that the cipher has to encrypt. > > Here is the widely recognized method of how to handle information in a > cryptographic application : > > 1. Decode the information into bits. This is done easily, for the > computer everything is already bits. > 2. Compress that information. There are algorithms for this. > 3. Encrypt the resulting bitstream. > 4. Encode the resulting bitstream into something suitable for its > purpose. If the file is meant to stay on the computer, omit this step, > otherwise - if it is meant to be sent by email for instance - encode > it in some email-friendly encoding, for instance Base64 > 5. Transmit the resulting encoded information > -- > 6. Decode the information using the reverse process of the one used to > encode it. > 7. Decrypt the resulting bitstream. > 8. Decompress the resulting bitstream. > 9. Encode the information into something suitable for its purpose. For > instance, if the decrypted information is meant to stay on the > computer, just save it as a binary file. If the decrypted information > is meant to be read quickly then ditched, encode it into the ASCII set > for instance (or Unicode for a wider variety of characters, including > asian characters). Hi, many thanks, 1. >Decode the information into bits. This is done easily, for the >computer everything is already bits. 2.> Compress that information. There are algorithms for this. 3.> Encrypt the resulting bitstream. 4.> Encode the resulting bitstream into something suitable for its >purpose. If the file is meant to stay on the computer, omit this step, >otherwise - if it is meant to be sent by email for instance - encode >it in some email-friendly encoding, for instance Base64 5.> Transmit the resulting encoded information -- 6. >Decode the information using the reverse process of the one used to >encode it. 7.> Decrypt the resulting bitstream. 8. >Decompress the resulting bitstream. 9. >Encode the information into something suitable for its purpose. For >instance, if the decrypted information is meant to stay on the >computer, just save it as a binary file. If the decrypted information >is meant to be read quickly then ditched, encode it into the ASCII set >for instance (or Unicode for a wider variety of characters, including >asian characters). 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
From: Sebastian on 16 Jul 2010 05:19
On 16 Jul., 08:03, adacrypt wrote: > My question is this: How in general, in modern Western cryptography > is textual data for encryption entered into a computer. Why don't you try to find this out by yourself ? Have a look at GPG, TLS, ... http://www.gnupg.org/ http://en.wikipedia.org/wiki/Transport_Layer_Security > I am speaking of ordinary plaintext from the > character set of printable ASCII. Character set doesn't matter. "plaintext" (as used in cryptography) doesn't imply a special encoding (ASCII, Unicode, ...). It just refers to the *encoded message* with whatever encoding you choose (could be a GZip-compressed stream of UTF-8 text or a JPEG image). It's been said already. You're mixing two or three things together that should have been handeled separately: encoding, encryption, armoring. > 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 This is nothing new. See GPG, 7zip, ... > 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. > > To me this seems the obvious thing to do. I cant understand why I am > being admonished to read bytes instead of plaintext as it appears. I think your confusion comes from the fact that you think "plaintext" implies human readable text encoded using ASCII. This is not the case. It's much more convenient to treat your plaintexts and ciphertexts as sequences of octets -- regardless of their encoding. > What gives here? - adacrypt I don't know. For some reason you seem to be immune to well-reasoned criticism. For some reason you seem to think your ciphers are worth investigating / using. I guess you should really try to understand why only crazy hobby cryptographers try to "optimize the OTP". Once you realized that anything as "safe" as the OTP is as useless you should focus on current state of the art methods (see block ciphers like AES). You might also want to take a look at how other applications handle all this. For example, try to figure out what happens if you use GPG in its symmetric mode (option "-c"). Cheers! SG |