Home > Archive > Java Security > February 2005 > Packet verification
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Packet verification
|
|
| Jeffrey Spoon 2005-01-28, 4:01 pm |
|
Hello, I'm using to Java to implement a simple p2p system. I have a
problem though - I would like to make sure the custom packets I'm
sending are the same packets which were sent, i.e. to prevent malicious
packet injection etc. I was thinking of using one of the hashing
Algorithms such as SHA-1 or MD5. But then I realised, if I put the hash
in the packet, then someone could simply lop off the hash, change the
packet and re-hash it and the receiver would be none the wiser. So would
I be better doing something along the links of public private key? I'd
like to keep it as anonymous as possible.
Cheers.
--
Jeffrey Spoon
| |
| Edward A. Feustel 2005-01-29, 8:56 am |
|
"Jeffrey Spoon" <JeffreySpoon@hotmail.com> wrote in message
news:09yJeEIKdm+BFwKq@nowhere.nnn...
>
>
> Hello, I'm using to Java to implement a simple p2p system. I have a
> problem though - I would like to make sure the custom packets I'm sending
> are the same packets which were sent, i.e. to prevent malicious packet
> injection etc. I was thinking of using one of the hashing Algorithms such
> as SHA-1 or MD5. But then I realised, if I put the hash in the packet,
> then someone could simply lop off the hash, change the packet and re-hash
> it and the receiver would be none the wiser. So would I be better doing
> something along the links of public private key? I'd like to keep it as
> anonymous as possible.
>
> Cheers.
>
>
>
> --
> Jeffrey Spoon
>
>
I am probably betraying ignorance here, but ...
I thought that one incorporated a "secret" in the hash known to the sender
or the
receiver. Then the hash won't be verified even if it is replaced unless the
attacker
knows and uses the "secret".
Ed
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
| |
| Edward A. Feustel 2005-01-29, 8:56 am |
|
"Jeffrey Spoon" <JeffreySpoon@hotmail.com> wrote in message
news:09yJeEIKdm+BFwKq@nowhere.nnn...
>
>
> Hello, I'm using to Java to implement a simple p2p system. I have a
> problem though - I would like to make sure the custom packets I'm sending
> are the same packets which were sent, i.e. to prevent malicious packet
> injection etc. I was thinking of using one of the hashing Algorithms such
> as SHA-1 or MD5. But then I realised, if I put the hash in the packet,
> then someone could simply lop off the hash, change the packet and re-hash
> it and the receiver would be none the wiser. So would I be better doing
> something along the links of public private key? I'd like to keep it as
> anonymous as possible.
>
> Cheers.
>
>
>
> --
> Jeffrey Spoon
>
>
And of course you can always sign the hash with your private key,
which presumably the attacker cannot do.
Ed
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
| |
| Jeffrey Spoon 2005-01-29, 3:58 pm |
| In message <41fb733c$1_1@127.0.0.1>, Edward A. Feustel
<efeustel@direcway.com> writes
>I am probably betraying ignorance here, but ...
>I thought that one incorporated a "secret" in the hash known to the sender
>or the
>receiver. Then the hash won't be verified even if it is replaced unless the
>attacker
>knows and uses the "secret".
>Ed
AFAIK (which isn't much, admittedly) you hash something. Then you
combine this with a private key. The other user then decrypts it with
your public key. I think this is what you mean by secret. But the actual
hash itself (e.g. SHA-1) is just a standard one way algorithm that gives
something a unique pattern so you can identify it.
So originally I thought of just hashing the packet contents and using it
much like a checksum. But then that only verifies the packet is the same
which was sent and not that it was sent from the same person.
The problem I have with public/private keys is that it identifies you to
the other person, which I don't really want. I'm assuming there's a way
around this. Maybe generating a random key each time may work or
something like that.
--
Jeffrey Spoon
| |
| Jeffrey Spoon 2005-01-29, 8:57 pm |
| In message <41fb73be$1_1@127.0.0.1>, Edward A. Feustel
<efeustel@direcway.com> writes
>And of course you can always sign the hash with your private key,
>which presumably the attacker cannot do.
>Ed
I didn't realise Java has SSE/SSL API's. Should I just use them instead,
and pass my application protocol through?
Cheers.
--
Jeffrey Spoon
| |
| Edward A. Feustel 2005-01-30, 8:56 am |
|
"Jeffrey Spoon" <JeffreySpoon@hotmail.com> wrote in message
news:6zfqNzA$e6+BFwqd@nowhere.nnn...
> In message <41fb733c$1_1@127.0.0.1>, Edward A. Feustel
> <efeustel@direcway.com> writes
>
>
> AFAIK (which isn't much, admittedly) you hash something. Then you combine
> this with a private key. The other user then decrypts it with your public
> key. I think this is what you mean by secret. But the actual hash itself
> (e.g. SHA-1) is just a standard one way algorithm that gives something a
> unique pattern so you can identify it.
>
> So originally I thought of just hashing the packet contents and using it
> much like a checksum. But then that only verifies the packet is the same
> which was sent and not that it was sent from the same person.
>
> The problem I have with public/private keys is that it identifies you to
> the other person, which I don't really want. I'm assuming there's a way
> around this. Maybe generating a random key each time may work or something
> like that.
>
>
>
>
>
> --
> Jeffrey Spoon
>
>
You could either sign the hash or you could use a "shared secret" a random
set of bits catenated
with the message to determine the SHA/MD5 but not transmitted. In either
case the other user
either has to "know something about you". Also if you use SSL, the other
entity will know your
IP address (unless you use an intermediary that protects your identity).
Anonymity is hard!
Ed
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
| |
| Mr. Skeptic 2005-01-30, 3:58 pm |
| I would say you should use the SSL APIs that come with Java. The crypto
operation you have been discussing is commonly know as a keyed hash or
keyed MAC or sometimes simply MAC (MAC==Message Authentication Code).
In its simplest form, both sides have the same key K. The sender
computes Hash(K || message) and appends it to the message. The receiver
gets the message , which we'll call message' since it may have been
tampered with, and computes Hash(K || message'). If it matches the
values that appended to the end of the message, the receiver knows
message == message'.
SSL gives you all this functionality and more, and is easy to use.
| |
| Jeffrey Spoon 2005-01-30, 3:58 pm |
| In message <41fcc8d1$1_1@127.0.0.1>, Edward A. Feustel
<efeustel@direcway.com> writes
>You could either sign the hash or you could use a "shared secret" a random
>set of bits catenated
>with the message to determine the SHA/MD5 but not transmitted. In either
>case the other user
>either has to "know something about you". Also if you use SSL, the other
>entity will know your
>IP address (unless you use an intermediary that protects your identity).
>Anonymity is hard!
>
>Ed
>
I see, so when hashing you basically use a random secret which only the
two communicators use. As for knowing the IP's, that is ok. I should
explain that the system I am trying to design is used for message
passing, much like a decentralised usenet system. However it uses IP
address to directly connect to peers dynamically. The anonymity element
comes in separating which IP posts which article. It's not intended to
be 100% bomb proof or anything, I just though it might help simple
malicious attacks. Although I had considered the intermediary which
resolves the IP, somehow. However that's quite tricky on a
de-centralised network AFAIK. Also I don't really want verification.
Sounds mad I know, but I would like any node to join without being
discriminated against (at the moment anyway).
You're right, anonymity is hard :)
Thanks.
--
Jeffrey Spoon
| |
| Jeffrey Spoon 2005-01-30, 3:58 pm |
| In message <1107102332.459869.238190@c13g2000cwb.googlegroups.com>, Mr.
Skeptic <ghstark@gmail.com> writes
>I would say you should use the SSL APIs that come with Java. The crypto
>operation you have been discussing is commonly know as a keyed hash or
>keyed MAC or sometimes simply MAC (MAC==Message Authentication Code).
>In its simplest form, both sides have the same key K. The sender
>computes Hash(K || message) and appends it to the message. The receiver
>gets the message , which we'll call message' since it may have been
>tampered with, and computes Hash(K || message'). If it matches the
>values that appended to the end of the message, the receiver knows
>message == message'.
>SSL gives you all this functionality and more, and is easy to use.
>
Yes, this is the way I'm leaning. How compatible is the Java SSL API?
It's likely other clients will be coded by other people, in C++ and
such.
Cheers.
--
Jeffrey Spoon
| |
| Mr. Skeptic 2005-02-01, 4:03 am |
| I have been playing around a bit with JDK5.0 client-side implementation
and it looks pretty standard, supporting most of the ciphersuites that
anybody would ever use. I would assume the server side is just as
usable.
| |
| Jeffrey Spoon 2005-02-01, 4:01 pm |
| In message <1107220861.957628.143960@f14g2000cwb.googlegroups.com>, Mr.
Skeptic <ghstark@gmail.com> writes
>I have been playing around a bit with JDK5.0 client-side implementation
>and it looks pretty standard, supporting most of the ciphersuites that
>anybody would ever use. I would assume the server side is just as
>usable.
>
Ah, you're still there ;) I haven't actually installed 5.0 yet, will do
shortly.
Thanks.
--
Jeffrey Spoon
|
|
|
|
|