I need to develop an Ethernet encryption scheme. All that needs to be done is take the input on Ethernet and encrypt the packets and send them out the output Ethernet. Is there ANY way I could do this for $35 a piece? How about $50?
Electronic – 2 Ethernet Ports and a FPGA
encryptionethernetfpga
Related Solutions
No, you can not assume there will be no signal on the line just because you're not deliberately sending something at the network packet layer. There are things called link pulses, and there can be other negotiation going on between the switch and the PHY and possibly the MAC.
The best thing to do would be to let the MAC and PHY do their jobs. You can use a microcontroller with a MAC and PHY to blip a pin whenever one of your packets is received. You'd write a very bare "driver" that just waits for a packet at the MAC layer, blips a pin, then clears the packet. With such dedicated firmware, the jitter it adds should be quite small.
If you are willing to slow down your packet rate, you can do this even more easily. Most switches and other ethernet devices have send and/or receive LEDs. These are often blipped for a few 10s of ms when a packet is sent or received, which is why sending one every 5 ms won't work. If you send a packet every 100 ms, the LED should be off again when the next packet arrives. You can also wire up your own PHY and set it up to blip a pin a short time for each packet. That's basically what the chip in the switch is doing when it drives the LED.
Let's get some terms straight first: An Ethernet interface is typically made from two parts: a MAC and a PHY. The MAC, Media Access Controller, handles all of the packet assembly, transmission, reception, and error checking. A PHY handles all of the PHYsical transport stuff like modulating the signal, managing the DC balancing, tracking baseband wander, etc.
There are some things that both sides do, to some extent. Both MAC and PHY do some level of data error detection. This is not redundant error detection, but just error detection that is related directly to the types of things that the MAC and PHY do. Also, both MAC and PHY are dependent on the packet nature of Ethernet. The MAC because it is using the packet nature to filter, route, and manage the data. The PHY because there are certain signal modulation/demodulation functions that require packets (and the space between packets) to function correctly.
The point is: You cannot get away from packets even if you just use the PHY. Of course, the packet headers do not have to be "standard" headers. And the CRC does not have to be a standard CRC. But you are still limited to the maximum packet length and inter-packet-gap that standard Ethernet requires. (Note: You might be able to do "jumbo" packets if both PHYs support it.)
There are many benefits to using standard Ethernet packet headers, however. We would refer to this as a "Layer 2" protocol. The main benefit is that you can use standard Ethernet switches to help connect different devices together.
You mention just connecting a "TDM stream" directly (more or less) to the PHY. Every time someone has said that to me they have been talking about running multi-channel digital audio over Ethernet. If that is the case then you have a bunch of other issues, like clock synchronization and error detection that will prevent you from doing it the easy way. I won't cover audio over Ethernet more in this answer, but tell me if that is what you want to do because I can add a lot more info in that case.
Historically there have been many products that have taken some sort of data stream and ran it over Cat-5 using Ethernet PHYs and FPGAs, but without traditional MACs. Some of them have used the proper Ethernet Layer 2 or Layer 3 packets, and some of them have not. Some have also used non-Ethernet technology like ATM or FDDI. Some of them have used FPGA's, but inside the FPGA is a more traditional CPU and MAC.
I hope that at this point you have realized that what you want to do (use an FPGA and PHY to transfer a data stream over Cat-5) is difficult. Not impossible, but difficult. Let me try to explain how difficult.
First, you will have to master FPGA logic design. Of all the professional FPGA logic designers I know of, this project is beyond the ability of maybe 95% of them. These are people who have been designing FPGAs for several years or even several decades. It will take you a long time to learn FPGAs enough to design this logic. Probably years if you are doing this as a hobby.
Next, you need to learn exactly what a MAC and PHY do, and how they interface. This is not as hard as learning FPGAs, but it isn't easy either. There are a lot of basic concepts that are important, but not easily learned.
Now you'll have to design a PCB to do all of this. Designing a reliable PCB that uses FPGAs, PHYs, and does all of the proper Ethernet signal integrity stuff is also not easy. Not super hard either. But on a scale of 1-10, with 1 being super easy, this PCB would be about a 6. Not hard for an experienced professional, but definitely hard for a non-professional-EE.
At this point you probably noticed that I didn't directly answer your questions. This was on purpose. I could answer your questions, but honestly that wouldn't help you. It would be like telling you how to build the second story of a house when you haven't figured out how to build the first story or even the foundation.
Start by learning everything about designing FPGAs that you can. Also learn everything about Ethernet that you can. There are lots of online resources from app notes, datasheets, and how-to's. Go to opencores.org and study their Ethernet MAC cores. Do this diligently and in a year you might be ready. And when you are ready then you will likely know the answers to 75% of your questions-- and you will be able to put the other 25% into proper context so when someone does give you an answer it will actually be useful to you.
Best Answer
I have a lot of concerns with this project, so let me brutally honest here. When it comes to cryptography the most dangerous thing is for someone who doesn't know about it to try implementing it. And honestly, you don't know about it. I say that because of your lack of caring about what encryption algorithm is used. I also don't think that you really know the computational resources required for public/private key encryption.
Even if you chose the correct encryption algorithm, and implemented it perfectly, that doesn't mean your device is secure. Most encryption security breaches are not from someone doing a brute force attack on the key, but from something else that is much easier and has nothing to do with the algorithm used. For example, if you encrypt the ethernet packet headers then you'll have better security, but you won't be able to send this data through a standard ethernet switch and/or layer 3 router. If you don't encrypt the headers then you're opening yourself up to a form of analysis and attack that could give someone information even without breaking the encryption.
A book that I highly recommend is Applied Cryptography. It talks about lots of issues with cryptography, and also goes through a lots of algorithms. It is a little dated in that it doesn't cover AES, but it does talk about many hash algorithms, DES, and public/private key encryption.
Ok, now on to your real question: Can it be done for $35/each? Absolutely! Can YOU do it for $35/each? Well, I can't answer that. You simply didn't give us enough information. For starters, is this a hobby project or something that will be made in volume? What is your case/chassis going to be? How is this going to be controlled, via LCD and buttons?
If you are only building two of these things then it is going to be very hard to get the price down to $35. It would actually be hard to get the price down below $250. But even in volumes of around 2K/year I would estimate that the PCB+parts would be in the $30-35 range and that doesn't factor in the cost of labor, a chassis, or an AC/DC power supply. Also, there might be cheaper ways to do this that don't use an FPGA.