Encryption?

[qmanjr5]

Would it be possible to take a text entered from a user and make it encrypted (Replace a with z, etc, etc?)

Also, do you guys think this would be a good year end project (FSE) where you have to make something in Turing that could be sold?

[DemonWasp]

Is it possible? Yes. Is it pretty trivial? Also yes.

A shift-cipher isn't sufficiently complicated or involved to qualify as a final project - that's more like an assignment. If you were to implement a GUI frontend, then maybe. What would be preferable is offering encryption and decryption with several different methods (shift and scramble ciphers are simple and easy, but you could definitely get better ciphers going, such as a XOR cipher).

XOR ciphers have the advantage that their encryption and decryption methods are the same thing - take the incoming text and XOR it against the key. This works because (plaintext) XOR (key) XOR (key) === (plaintext).

If you had multiple ciphers to encrypt text, file-I/O, some kind of user interface (text is fine), and the ability to decode existing files, then it might be a decent final project. For bonus points, consider adding a feature to decrypt any file your program produces without the user telling you what kind of encryption is used.

[qmanjr5]

Exactly what I was thinking of doing.
A nice GUI, several options (encrypt file, decrypt file, encrypt text, decrypt, etc)
So yeah, thanks.

how would I go about doing the actual encryption code (not the method)

[Insectoid]

There are many ways.

You could read in a value of length X and submit it to various functions to generate a new value (be it string, number, expression, etc). Take another string of length X, repeat, until the whole file is encrypted.

[USEC_OFFICER]

You could divide the string into equal sections, add extra letters through between each section, then put it through a cipher, (With spaces equaling a letter).

You could also assign each letter a value, then preform mathatical operations on it.

[Insectoid]

In short, it's done however you want it to be done. There is no 'one way' to do it.

[DemonWasp]

The easiest way to handle the actual encryption would probably be to have each encryption scheme work like a channel. Your encrypt/decrypt methods would read from a stream (there's a streamID for files and the console too) a few characters at a time, then output to another streamID.

For most ciphers I've listed (shift, scramble), you should work with one character at a time. Your encryption would be something like:

code:

loop   c = read-character   e = encrypt ( c )   output-character ( e ) end loop

You can probably imagine how a decryption scheme would work similarly for those ciphers.

For a XOR cipher, you almost certainly want to read characters in batches of length N (and, if input terminates in the middle of such a "block", pad it out with 0*). You would then encrypt whole blocks at a time, and output whole blocks at a time.

* That's not secure, because it provides some known-cleartext for an attacker to examine your algorithm with (they know it ends in some number of zeroes). I don't think the real intention here is security, so that shouldn't be a problem.

[DtY]

There are two general kinds of ciphers, stream ciphers and block ciphers.

Just a note on terminology here, plain text is the input to the program (even if it's not text, but say, an image), cipher text is the output of the program.

A stream cipher works on single bytes (or bits), one byte at a time uses some algorithm to transform that single byte of the plain text into the cipher text. Depending on the algorithm, the position in the stream would be taken into account (two of the same characters in a row wont necessarily become the same in the cipher text).

A block cipher takes a block of input of a predetermined size, and transform that whole block into the cipher text at once. The down side of this is that the input needs to be made into a size that is a multiple of the block size, by padding it as DemonWasp explained.

Rather than using just NULLs though, which is susceptible to a known text attack (which is a cryptographic weakness caused by the attacker knowing through some means part of the plain text, in this case the padding is NULLs) is to store the total size of the plaintext in a file header, and then adding random padding at the end.

---

If this project is something you are interested in, you should read into some ciphers that are currently in use, for example the Advanced Encryption Standard (AES), which is strong enough for the NSA to use for top secret information.

The down side to a cipher like NSA is that you can't use a key of any size, so you can't just have the user enter a password, you'll need to either generate a random key and store it in a file, or use some method to generate a key based on a password, that will always give the same key given the same password. The latter is much more involved though.