2
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ How fast does it need to be? 10/100/1G/10G? Also, what encryption, AES, 3DES or something else? \$\endgroup\$ – Pentium100 Apr 15 '12 at 23:23
  • \$\begingroup\$ Any. Preferably 100 MBps with public key encryption. \$\endgroup\$ – unixman83 Apr 15 '12 at 23:26
  • 2
    \$\begingroup\$ -1 for "Drink deep ... the Pierian Spring" fail. +1 for "All that needs to be done ..." :-). Overall, a wash. \$\endgroup\$ – Russell McMahon Apr 16 '12 at 3:45
  • \$\begingroup\$ How do you plan on decrypting the packets? Perhaps it would be easier to utilze existing VPN technologies such as IPsec or L2TP via some sort of embedded linux platform / board instead of going the FPGA route. \$\endgroup\$ – Craig Apr 16 '12 at 13:38
  • \$\begingroup\$ @Craig with software. I would only encrypt the content of the packets, not the 16 byte Ethernet header. So it would still work with traditional switches and computers. They wouldn't be able to decipher the content of the packets. \$\endgroup\$ – unixman83 Apr 17 '12 at 10:29
7
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ What are the cheaper ways? In creating an internet content filter, I simply need to obfuscate the packets so only my software can read them. This prevents teenagers from getting around the software by hacking it or removing it. The only hardware will be a simple Ethernet plug that encrypts packets. \$\endgroup\$ – unixman83 Apr 16 '12 at 0:39
  • 1
    \$\begingroup\$ @unixman83 TI has an ARM Cortex A8 CPU with dual GigE Ports and costs about $10 in quantity. Other companies make similar things. Here's a link to the TI version: ti.com/product/am3357 \$\endgroup\$ – user3624 Apr 16 '12 at 1:07
  • \$\begingroup\$ Oh, the TI parts also have what they call a "Crypto accelerator", whatever that means. \$\endgroup\$ – user3624 Apr 16 '12 at 1:08
  • 1
    \$\begingroup\$ David, iirc they add functions to accelerate AES key scheduling and the round function. \$\endgroup\$ – drxzcl Apr 16 '12 at 11:01
  • \$\begingroup\$ @DavidKessner Thanks for the knowledgeable answer. I like the TI ARM CPU. We're probably going for a software only solution for now but I'll keep that link handy if things change. \$\endgroup\$ – unixman83 Apr 17 '12 at 10:28
0
\$\begingroup\$

The lowest cost hardware with two ethernet ports and some processing power between would be two PIC 18 67J60 connected together. Each has it's own ethernet interface, and they could communicate using their built in UARTs between them on the same board. The parts cost should be under $20 for the two PICs, two transformers, two RJ-45 jacks, and the board. If you already have regfulated 3.3 V available it needn't be much more than that.

That setup is certainly capable of passing packets from one port to the other and applying some sort of modification in between. Whether is is fast enough for what you have in mind we don't know. That all depends on how complicated your encryption algorithm is and what data thruput you expect.

You say you are only dealing with packets at the ethernet level. If that is really true, then something like this might work. Without a full blown TCP stack, the chips should be able to handle a higher data rate. However, have you really thought this thru? How do you know which packets to encrypt without at lest some analysis at a higher level? You could transform only TCP/IP packets, for example. That's easy enough to detect, but do you really want to scramble the whole packet, including the TCP header? What about the IP header? If you scramble that, how are your packets going to get routed? It doesn't sound like you've really thought this out all the way. Hardware to do this is probably the least of your problems.

How about a PC with two network cards?

\$\endgroup\$
  • 4
    \$\begingroup\$ The PIC that you specify does 10.5 MIPS, which is less than 1 instruction/byte at full 100 mbps speed and at half duplex. Full duplex would be twice as bad. My GUESS is that this solution would only be able to achieve 10 mbps sustained, best case, and could be much worse. The problem is that if the PIC receives a burst of more than 8 kbytes at 100 mbps then it will start dropping packets. What's the likelihood of getting such a burst? Extremely high, in my experience, given how this device would be used. \$\endgroup\$ – user3624 Apr 16 '12 at 1:45
  • \$\begingroup\$ @David: Right, I mentioned this as the cheapest solution I know, definitely not the highest thruput. The OP didn't say anything about thruput in his question. Also, this is only 10 Mbit/s ethernet anyway, so can't get 100 Mb/s packets. Remember, this processor is meant for small embedded systems. \$\endgroup\$ – Olin Lathrop Apr 16 '12 at 12:53
  • \$\begingroup\$ Silly me. The docs say "Fully Compatible with 10/100/1000Base-T networks", which I interpreted to mean that it does 10/100/1000 mbps. The problem of dropped packets still remains, but the packets would be dropped at the 100/1Gig switch instead of the PIC. \$\endgroup\$ – user3624 Apr 16 '12 at 14:56
  • \$\begingroup\$ @David: Yes, it's fully compatible if you put a switch as a converter in between. Technically it's fully compatible in that the higher rates are only if both devices agree. 100 Mb/s devices have to be able to do 10 Mb/s. It's just like saying you're "USB 2.0" compatible even if you only do 12 Mb/s. It's a bit misleading but technically correct. 10 Mb/s is a lot of data for a small embedded system, so that's not a limitation in actual use. \$\endgroup\$ – Olin Lathrop Apr 16 '12 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.