Archived

This topic is now archived and is closed to further replies.

Jade

Network sniffers?

Recommended Posts

Hey all. I''m getting rather close to finishing a networking application, though as I started to scrutinize its security, I realized that my network traffic using the program was blatantly visible using any of the freeware network sniffers/shims. I was wondering if any of you generally knew of any methods to beat or fool such programs, or to disguise transmitted data in such a way that it becomes unreadable. I know I could use SSL, but it really isn''t warranted for this project. Thanks in advance, jade

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
There are 2 ways (that i can think of) that you can deal with this.
1. Encrypt your data so that packet sniffers just can''t make sense of it. (use DES or whatever to encrypt). You should probably also use number 2 to make sure that packet data hasn''t been "randomly" modified.
2. Leave your data open (unencrypted) but use a verification scheme, such as a checksum, to make sure that the contents of the packet haven''t been modified.

Number 1 works in cases of hiding your data, and preventing it from being modified. Number 2 only prevents your data from being modified but leaves the actual data open to be read by anyone.
Number 1 takes more time to process than number 2 (depending on algorithms of course, but most likely encryption will take longer than a checksum), so if you need a lot of speed, and don''t mind people being able to read your packets, as long as they can''t be modified, go for number 2.
Hope that helps a little.

Share this post


Link to post
Share on other sites
try both: first checksum, then encode message, next another checksum, to checksum prefer md5, to encode rc5. Its nearly undecodable (4 years on 10mil computers its enought for one packet i think)
Bad thing is that you must someway acknowlege client about rc5 code you use. I prefer randomly generated 64-bit one-use code in some table, generated for each client.
I think i will be enought , but remeber nothing is really unbreakable.

Share this post


Link to post
Share on other sites
try both: first checksum, then encode message, next another checksum, to checksum prefer md5, to encode rc5. Its nearly undecodable (4 years on 10mil computers its enought for one packet i think)
Bad thing is that you must someway acknowlege client about rc5 code you use. I prefer randomly generated 64-bit one-use code in some table, generated for each client.
I think i will be enought , but remeber nothing is really unbreakable.

things more:
most of sniffers are vulerable to simply ping, so ping any computers on their traceroute
most of sniffers (i dont know why) gather info only from lower ports so make your connection at about 65000
most of sniffers set flag IFF_PROMISC, there is a method to find if any card has this flag set (make connection, see flags at TCP header) so if it is set its PROPABLY sniffer

Share this post


Link to post
Share on other sites
quote:
Original post by moore52
try both: first checksum, then encode message, next another checksum, to checksum prefer md5, to encode rc5. Its nearly undecodable (4 years on 10mil computers its enought for one packet i think)
Bad thing is that you must someway acknowlege client about rc5 code you use. I prefer randomly generated 64-bit one-use code in some table, generated for each client.
I think i will be enought , but remeber nothing is really unbreakable.



What''s the overhead with that approach?

Share this post


Link to post
Share on other sites
Thanks to all who responded. I''ve taken your advice and encrypted my traffic (448-bit blowfish) but had a small general question. If I wanted to make my encryption just a bit more difficult to crack, would it be a good idea to scale the data by a pre-determined constant of some sort beforehand (i.e. (String * 2)), or would this actually weaken the overall security? Do you have any other ideas that are similar to this approach? Thanks.

Regards,
Jade

Share this post


Link to post
Share on other sites
I'm working on network security also.

multiplying by a constant won't help. Anything that simple can be figured out by someone else quickly. Blowfish is plenty.

"Cryptography and Network Security: Principles and Practices" by William Stallings is a good book for learning about network security. It talks about encryption and protocols. You'll get a good sense of how modern encryption works and how to write a secure protocol. The 3d edition just came out so its very current infomation also.

448 bit blowfish seems like huge everkill to me. Especially for a game. Every bit doubles how hard it is to brute force through each key. The online stores I've looked at are using 128 bit RC4.

I'm using the openssl crypto library for 128 bit blowfish encryption, md5, and rsa. Rsa is used authenticate the client and server and send session keys. md5 as part of the authentication of data. Blowfish for the encryption of the majority of important data.

I'm designing the protocol at the moment.

If you are using tcp I'd use SSL. It would be much less work.

kdIXfA.gamedev.10.coreyh@spamgourmet.com
www.ipeg.com/~rlfc

[edited by - coreyh on October 7, 2002 12:54:57 AM]

[edited by - coreyh on October 8, 2002 5:53:09 PM]

Share this post


Link to post
Share on other sites
Compression is something that can help if you do it before encryption. I would only do it if your data is large enough that it actually decreases the size. I haven''t worked with it yet so I can''t say how big that is. The packets that I''m using now are so small I have a hard time imagining it helping.

The theory is it makes the data more complex so its harder to know after cryptoanalysis if it was unencrypted correctly or not.

wierdd@hotmail.com
www.ipeg.com/~rlfc

Share this post


Link to post
Share on other sites
compressing the data before encryption doesn''t make the data more komplex. it even makes the package easier to decrypt if you use well known methods like zip or something else.

compressed data has special characteristics and attackers can use the information about the characteristics of the compressed data to break your coding.

like if compressed, first 16 bit word can only contain values from 0 to 256, second can only contain 0 to 257..., this information can help to recognize wrong keys pretty early and even without knowing the format of the compressed data.
so take care if you say compressed-encoded data is harder to attack than uncompressed.

Share this post


Link to post
Share on other sites
http://www.ciphersbyritter.com/NEWS6/KNOWNPLN.HTM

makes it sound like known plaintext doesn''t seem to be a issue with modern encryption yet

but I was wrong about what I said. The book was just talking about it being harder to identify then plain english text.




kdIXfA.gamedev.10.coreyh@xoxy.net
www.ipeg.com/~rlfc

Share this post


Link to post
Share on other sites