Network sniffers?
Author
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
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.
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.
Why not use SSL. Look at OpenSSL it''s free....
Or like Anon said, write your own encryption routines etc...
Or like Anon said, write your own encryption routines etc...
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.
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.
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
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
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
What''s the overhead with that approach?
Author
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
Regards,
Jade
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]
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]
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
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
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
