Hi everyone,

I'm currently studying electronics on day release from work, one of the projects I have is to

1)network two 6502's together via fibre optic
2)take some data from one memory location encode the data
and transmit the information over the fibre optic link.
3) The second 6502 will receive the data decode and store in another memory location.

Any pointers to help from you experts would be a great help, I've managed to build the fibre optic interface, but I'm a unsure about the encoding.

Cheers JT (jt@supanet.com

Sounds like a fun project!

Can you clarify what you mean by 'encoding'?
I can think of at least 3 possible meanings:
1) Simply changing the data into some serial form so that you can send it over the fiber link (like what a UART does).
2) 'Encryption', for the purpose of hiding the meaning of the data that you send. You used this word to title your post - is that what you meant?
3) Encoding data into a serial form that requires fewer state transitions, thus improving bandwidth. An example is the "2/3 code" that I learned about 18 years ago, which was (and perhaps still is) used to improve the bandwidth of data being written to a disk.

Both 2) and 3) are very interesting topics.
I've studied a little of 2) as it pertains to radio communications - let me know if you suggestions for encryption algorithms.

Pete

Hi Pete,

Thank for your reply sorry for the delay in responding, but have been kept busy with work, the project I suppose can be split into two different phases

1)Investigate Algorythms for the purpose of encoding data, perhaps written text which can be encoded in a way that it becomes illegible to anyone reading the material in it's encoded state, but must also able to decode successfuly.

2)Sending the Data down a fibre optic link.

If I manage to encode/decode succesfully on one 6502 then this programme can be loaded onto the second 6502 allowing encoded/decoding Tx and Rx from both processors.

Cheers JT

You might want to get a book on 'codes and ciphers'.

Some general ideas:
- Do your encryption on 'blocks' of text (i.e. an entire message), not on individual letters.
- Many schemes are based on multiplying by a large prime number.
- Learn how the WWII German "Enigma" machine worked, and emulate it in software. I helped my nephew write such a program in Pascal, and it wasn't hard at all.
- Do a "one-time pad" scheme, using a software random-number generator to create the pad (both systems must use the same seed in the random-number generator).

Pete

Thanks for the advise,I'll start doing some reasearch.

Cheers JT

The most basic form of encryption, in the classical sense, is one in which a "key" is stored in one place and the data to be encrypted in another. The encryption is performed bitwise by using two shift registers, one through which the raw data flows and one through which the key flows. The outputs of the two shift registers are fed to an XOR gate and the resulting bit is the corresponding bit of the output, called a "cipher" in some circles. This is a simple but quite difficult scheme to defeat, unless something is known about the key. If one has both the complete cipher and the complete, key, the same process is performed in the same order, and that process will "decrypt" the cipher, returning the clear data as the output from the XOR.

CRC generator/checkers work on this same principle, with the exception that their work is to produce a check character, which resides in the stream AFTER the data. On reversing the process, the n bits, where an n-bit key is used, following the data should be zero. That is indicative of a successful translation.

This type of enciphering is easy to accomplish in software, and I'd recommend you experiment with it in order to obtain some measure of confidence.

There are a number of ways in which one can frustrate the "cracker" with one or another trick, or combination thereof. One example is to use a second key with which to encipher the first. The two keys do not have to be of the same length, but they must recirculate in order to encipher streams of data longer than the key. For experimentation I'd recommend you use relatively short keys, e.g. 8 bits or so.

Another, acutally quite fiendish trick is called "cipher feeback." In this scheme, you take the encrypted data coming out of the first xor, and encrypt the key with it as it is being used. Deciphering logic becomes somewhat more complex with this scheme, since timing is critical.

Yet another even more fiendish scheme is "one-bit-cipher-feedback" in which only one bit of each 'm' bit group of the cipher is fed back to encipher the original key, and a very difficult to decipher variation of this one in which the enciphered key is used to determine which bit is used to encipher the key prior to enciphering the data. All this is VERY simple to do in hardware, and quite straightforward to perform in software.

Try it! You'll be surprised how handy that XOR function is.

Uli

>The encryption is performed bitwise by using two shift registers, >one through which the raw data flows and one through which the key >flows. The outputs of the two shift registers are fed to an XOR gate >and the resulting bit is the corresponding bit of the output, called >a "cipher" in some circles.

This scheme is essentially the same as the "one-time pad" scheme used frequently by spy-types until about the 60's (when other schemes using fancy hardware became more common).
Instead of an XOR function, a look-up table was used - it was called a Vigenere's Tableau.
For info on OTP's and such, see this part of my web page:
http://www.geocities.com/saipan59/clan_radio/otp.html

Using the XOR scheme as Uli describes is only secure if the key is changed with every message (as with a OTP). If you keep using the same key, a professional or skilled amateur will break it quickly.
Of course, 'secure' is a relative term - are you trying to hide the content from your kids, or from the NSA?

One of the 'rages' these days for encrypting computer-oriented messages is 'public key encryption'. The PGP software uses it.
As I mentioned in 37.4, the algorithm involves using very large
prime numbers. It is very strong encryption - strong enough that the NSA doesn't like the fact that it's in the public domain.

Pete

If you'd like a really well-characterized, extremely difficult-to-penetrate encryption algorithm secure enough that knowing the algorithm is absolutely not enough to facilitate cracking the code, so to speak, then look at Federal Information Processing Standards Publication #46, which describes their DATA ENCRYPTION STANDARD (DES).

That one is difficult and costly to process if you're an intruder. It's held up handsomel over the years.

Uli