Bryan Ponnwitz wrote: > I've designed an HR system for the company that I work for and part of > the system is a server application which allows for program updates to > be downloaded, messages to be sent to users and provides the ability to > kick users. For this, I've developed my own protocol running on port > 7282/tcp. Since this server is what I use for authentication, I had to > build some encryption into the protocol so that usernames and passwords > weren't being transmitted cleartext. My question is, how safe am I > using this encryption? Not at all. 1. The "encryption" algorithm (if it's worthy of that term, and I don't really think that it is) is about as secure as rot-13; i.e. not at all. 2. The key "negotiation" is even worse. Anyone who can sniff the traffic gets to see the raw key. Not that they really need it. > I've heard that homegrown encryption is asking > for trouble, but it seems to me that it would be difficult to break it. Then your understanding of cryptography is, basically, absolutely zero. OK, so that's not particularly kind, but to I don't know how to put it any other way without creating the possibility that someone else who reads this might be left in some doubt as to just how bad this is. Hint: look for patterns in the "encrypted" data. Real encryption algorithms produce data which looks more or less random. Yours produces: EC 03 00 00 70 40 00 40 AB 35 AF A0 70 42 B 00 40 5B BD 47 CA 76 42 r 00 40 7A A6 58 B0 77 42 y 00 40 A2 62 8C 9B 74 42 a 00 40 B7 5C D0 46 76 42 n 00 80 72 00 71 86 68 42 [space] 00 40 E9 07 D1 6C 72 42 P 00 40 E0 34 AE 67 76 42 o 00 40 B7 5C D0 46 76 42 n 00 40 B7 5C D0 46 76 42 n 00 40 28 F6 9C 6E 77 42 w 00 40 EA 23 7B A2 75 42 i 00 40 AD 6D 03 0C 77 42 t 00 40 A3 7E 36 D1 77 42 z 00 40 09 0D 8C 88 76 42 p 00 40 A2 62 8C 9B 74 42 a 00 40 84 95 25 EB 76 42 s 00 40 84 95 25 EB 76 42 s 00 40 28 F6 9C 6E 77 42 w 00 40 E0 34 AE 67 76 42 o 00 40 5B BD 47 CA 76 42 r 00 40 1D EB 25 FE 74 42 d The first two bytes are always 00 40 (except for space), the last is always 42, the next to last is 68-77 (or 70-77 excluding space). Far from random. This alone should tell you that it's no good. How to crack this scheme: 1. "encrypt" each of the 256 possible bytes, and store the "encrypted" forms in a lookup table. 2. For each 8-byte sequence, look it up in the table to discover the corresponding cleartext byte. Note that *any* scheme which tries to "encrypt" individual characters in a stateless[1] manner is subject to exactly the same attack. [1] i.e. duplicate input characters result in duplicate output sequences; e.g. in the above sample, note that all three occurrences of "n" result in the same sequence: "00 40 B7 5C D0 46 76 42". Such schemes are called "substitution ciphers", and a clued-in ten-year-old could reasonably break them without knowing the key, or even the algorithm. Consequently their use tends to be confined to the sort of toys which are given away with packets of breakfast cereal (the "Captain Midnight decoder ring"). > In any case, this is the encryption method that this program will use > since it's about to go into production, so please don't suggest > alternatives; I'm only looking to evaluate the method I've developed. > I've outlined my encryption methods bellow; take a look and let me know > how tough you think it would be to crack. Well, it took me less than five minutes, most of which was spent re-reading the description just to make sure that I hadn't missed something obvious and that it really was as bad as it looked. And I'm not a cryptanalyst. By which, I don't mean that I'm not a "professional" cryptanalyst, I mean that I'm not any kind of cryptanalyst, not even an novice amateur. I just happen to have absorbed enough really, trivially basic knowledge of cryptography to be able to spot a really obvious no-hoper. -- Glynn Clements <glynn.clementsat_private>
This archive was generated by hypermail 2b30 : Fri Sep 06 2002 - 14:47:21 PDT