Thread: Re: [Algorithms] Message signature in token ring (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Javier A. <ja...@py...> - 2003-04-17 18:46:58
|
Thierry Tremblay wrote: > The Windows CryptoAPI provides standard compliant implementation of > well known cryptographic algorithms (RSA, 3DES, RC2, SHA, MD5, ...). > So I am quite curious as to why everyone is talking about portability > issues, there is none. The point is that if you are writing a game for several platforms, using a platform-specific API in one of your targets doesn't help when you need to get it working in another target that doesn't have such an API. If you're going to use a full source code implementation in one target (possibly an open-source implementation), you might just use it in all of them. |
|
From: George M. <gf...@ya...> - 2003-04-17 19:43:14
|
While your basic statement is true, there are some borderline cases to consider here... Since I mostly agree with what Tony has suggested about the potential for very subtle errors (involving things such as paging to disk, etc) when implementing these algorithms, consider a situation where you're using one of the CryptoAPI supported ciphers to talk from an MMOG Windows-only client to a UNIX-based backend. In this situation, I'd feel pretty good about using CryptoAPI on the Windows side and then just rolling my own, or using Joe Random's open source implemention, on the UNIX side. When it comes to these subtle exploitable errors the implementation on the client is, IMO, more important to have exactly correct since it will be in the hands of the "enemy" and they will be able to look at every dark corner of it. Obviously doing something stupid like putting an exploitable buffer overflow in my server-side implementation would be troublesome, but the very minute details like not paging the plaintext out to disk are pretty insignificant -- if the attacker has already hacked into my server to the point where this is an issue, I'm already screwed no matter what. --- Javier Arevalo <ja...@py...> wrote: > The point is that if you are writing a game for > several platforms, using a > platform-specific API in one of your targets doesn't > help when you need to > get it working in another target that doesn't have > such an API. If you're > going to use a full source code implementation in > one target (possibly an > open-source implementation), you might just use it > in all of them. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: Chris H. <ch...@d6...> - 2003-04-17 20:05:14
|
Tony's original point was not to roll your own crypto. That point is totally valid, and I agree with him in that you'd have to either be insane, stupid, or a crypto expert to roll your own if you cared at all about security. Some people may have preferences for OSS and some may have preferences for OS APIs. That's not the important part of the point, in my opinion (and Tony's), although there is a discussion there to be had between open minded engineers that does not degenerate into name calling and insinuation (which we obviously didn't have :). He was not bashing game programmers at all, at least by my reading of his mails. Trying to write your own crypto code by asking beginner questions on this list is insane or stupid or both, unless you're just messing around to learn, and even then you should be reading one of the zillions of well written books and websites on the topic, not posting "how do I implement a secure login procedure" here. Hopefully that point comes through all the silly noise. I doubt anybody reasonably experienced would disagree with it. Chris |
|
From: Space N. E. P. <SPA...@ho...> - 2003-04-17 20:34:37
|
I started the thread and the whole point wasn't even about writing my own crypto lib at all. I was asking about the proper crypto tools/algorithms to use for a protocol I was attempting to design. I don't think anyone on the whole thread even ever suggested rolling their own lib. People just love their APIWARS!@# I suppose. I mean, we managed to cover CryptAPI, DirectPlay, AND DirectSound! I guess D3D must have had a by this round. ----- Original Message ----- From: "Chris Hecker" <ch...@d6...> To: <gda...@li...> Sent: Thursday, April 17, 2003 12:59 PM Subject: Re: [Algorithms] Message signature in token ring > > Tony's original point was not to roll your own crypto. That point is > totally valid, and I agree with him in that you'd have to either be insane, > stupid, or a crypto expert to roll your own if you cared at all about > security. Some people may have preferences for OSS and some may have > preferences for OS APIs. That's not the important part of the point, in my > opinion (and Tony's), although there is a discussion there to be had > between open minded engineers that does not degenerate into name calling > and insinuation (which we obviously didn't have :). He was not bashing > game programmers at all, at least by my reading of his mails. > > Trying to write your own crypto code by asking beginner questions on this > list is insane or stupid or both, unless you're just messing around to > learn, and even then you should be reading one of the zillions of well > written books and websites on the topic, not posting "how do I implement a > secure login procedure" here. > > Hopefully that point comes through all the silly noise. I doubt anybody > reasonably experienced would disagree with it. > > Chris > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
|
From: Jon W. <hp...@mi...> - 2003-04-17 22:11:07
|
> DirectPlay, AND DirectSound! I guess D3D must have had a by this = round. I have a driver right here which seems to apply encryption to my=20 texture surfaces, and sometimes to my framebuffer surfaces, especially=20 when the user changes the display settings while playing. Anyone=20 care to suggest a plausible attack against this to make it use=20 plain data? ;-) Cheers, / h+ |
|
From: Aaron N. <ani...@mi...> - 2003-04-17 20:41:50
|
I think some of the crosstalk was due to the concurrent "MMOG Logon" thread, from which the concept of rolling your own API emerged. -----Original Message----- From: Space Needle Exchange Program [mailto:SPA...@ho...]=20 Sent: Thursday, April 17, 2003 1:35 PM To: gda...@li... Subject: Re: [Algorithms] Message signature in token ring I started the thread and the whole point wasn't even about writing my own crypto lib at all. I was asking about the proper crypto tools/algorithms to use for a protocol I was attempting to design. I don't think anyone on the whole thread even ever suggested rolling their own lib. People just love their APIWARS!@# I suppose. I mean, we managed to cover CryptAPI, DirectPlay, AND DirectSound! I guess D3D must have had a by this round. ----- Original Message ----- From: "Chris Hecker" <ch...@d6...> To: <gda...@li...> Sent: Thursday, April 17, 2003 12:59 PM Subject: Re: [Algorithms] Message signature in token ring > > Tony's original point was not to roll your own crypto. That point is > totally valid, and I agree with him in that you'd have to either be insane, > stupid, or a crypto expert to roll your own if you cared at all about > security. Some people may have preferences for OSS and some may have > preferences for OS APIs. That's not the important part of the point, in my > opinion (and Tony's), although there is a discussion there to be had > between open minded engineers that does not degenerate into name calling > and insinuation (which we obviously didn't have :). He was not bashing > game programmers at all, at least by my reading of his mails. > > Trying to write your own crypto code by asking beginner questions on this > list is insane or stupid or both, unless you're just messing around to > learn, and even then you should be reading one of the zillions of well > written books and websites on the topic, not posting "how do I implement a > secure login procedure" here. > > Hopefully that point comes through all the silly noise. I doubt anybody > reasonably experienced would disagree with it. > > Chris > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
|
From: Thierry T. <ttr...@re...> - 2003-04-17 20:51:53
|
>I started the thread and the whole point wasn't even about writing my = own >crypto lib at all. I was asking about the proper crypto = tools/algorithms to >use for a protocol I was attempting to design. I don't think anyone on = the >whole thread even ever suggested rolling their own lib. People just = love >their APIWARS!@# I suppose. I mean, we managed to cover CryptAPI, >DirectPlay, AND DirectSound! I guess D3D must have had a by this round. Such is the nature of the Internet... |
|
From: Dave M. <dm...@od...> - 2003-04-15 17:16:40
|
Tom Forsyth wrote:
>
> >Does such an encryption algorithm ("encrypt with private key, decrypt
> > with public key") exist?
> > [...]
> > If it involves sending some kind of key/signature in every message, it would
> > be nice to keep that <= 128 bits. The protection doesn't have to be super
> > strong, since there is no incentive to crack, other than creating mischief.
>
> Certainly - PGP for example. But they're very slow.
Not too mention that there's not a one that meets his requirements for
< 128 bits of overhead. RSA's minimum message length is the length of
the modulus, which, given that we're doing games on this list rather
than sending state secrets could be in the 256-384 bit range, but this
is still a lot of overhead to go through. (El Gamal's message length is
2x the modulus, which is even worse.)
> Best way to do this is to securely (e.g. with public/private key stuff) send
> a client ID to each client at start of day - just a fairly big random
[...]
> The server recieves the message, appends the client's key, hashes it, and
> checks the hashes agree.
> Another user can't spoof because they don't know the key, and so can't
> generate a valid hash.
He specified peer connections here though, so I don't think this one
is appropriate. (Though it's definitely plenty secure for cli/ser
games.) Probably the best thing to try in this situation is have the
client, using Diffie-Hellman or another key exchange protocol, negotiate
keys with every other peer in the ring. DH is fairly straightforward,
and has been unencumbered by patents in the US for several years now.
Negotiate a 56-bit DES key, and either encrypt your payload (0 space
overhead, higher CPU overhead), or encrypt a hash at the end (small
space overhead, small CPU overhead). DES works on 64 bit blocks, so
appending an encrypted hash is pretty low overhead. It's not totally
secure, but it'll do for a game.
> But really, you need a proper crypto book - this has all been solved before,
> with a lot more rigour.
Amen. I highly recommend Bruce Schneier's "Applied Cryptography" if
you're really interested.
...dave
|
|
From: Space N. E. P. <SPA...@ho...> - 2003-04-15 17:47:41
|
Well, I had originally thought I would need a 16 byte GUID and a 16 byte
(128 bit) public key in each message, for a total of 256 bits, but now I
realize/believe that the public key can BE the GUID, therefore a public key
of 256 bits MAY be acceptable. I just don't know. But you can explain more
what you meant by "RSA's minimum message length is the length of the
modulus"?
I've considered that kind of direct key exchange followed by symmetric
encryption, but I would like to avoid requiring peers to directly connect to
each other. I guess though that these keys can be cached up and I would only
need to do it when I meet a totally new peer, though. So it's a possibility.
(And given the payload overhead of PGP, sounds like this route may be
inevitable.) I think it would prevent two firewalled peers from ever being
able to talk, however.
snx
----- Original Message -----
From: "Dave Moore" <dm...@od...>
To: <gda...@li...>
Sent: Tuesday, April 15, 2003 10:16 AM
Subject: Re: [Algorithms] Message signature in token ring
> Tom Forsyth wrote:
> >
> > >Does such an encryption algorithm ("encrypt with private key, decrypt
> > > with public key") exist?
> > > [...]
> > > If it involves sending some kind of key/signature in every message, it
would
> > > be nice to keep that <= 128 bits. The protection doesn't have to be
super
> > > strong, since there is no incentive to crack, other than creating
mischief.
> >
> > Certainly - PGP for example. But they're very slow.
>
> Not too mention that there's not a one that meets his requirements for
> < 128 bits of overhead. RSA's minimum message length is the length of
> the modulus, which, given that we're doing games on this list rather
> than sending state secrets could be in the 256-384 bit range, but this
> is still a lot of overhead to go through. (El Gamal's message length is
> 2x the modulus, which is even worse.)
>
> > Best way to do this is to securely (e.g. with public/private key stuff)
send
> > a client ID to each client at start of day - just a fairly big random
> [...]
> > The server recieves the message, appends the client's key, hashes it,
and
> > checks the hashes agree.
> > Another user can't spoof because they don't know the key, and so can't
> > generate a valid hash.
>
> He specified peer connections here though, so I don't think this one
> is appropriate. (Though it's definitely plenty secure for cli/ser
> games.) Probably the best thing to try in this situation is have the
> client, using Diffie-Hellman or another key exchange protocol, negotiate
> keys with every other peer in the ring. DH is fairly straightforward,
> and has been unencumbered by patents in the US for several years now.
> Negotiate a 56-bit DES key, and either encrypt your payload (0 space
> overhead, higher CPU overhead), or encrypt a hash at the end (small
> space overhead, small CPU overhead). DES works on 64 bit blocks, so
> appending an encrypted hash is pretty low overhead. It's not totally
> secure, but it'll do for a game.
>
> > But really, you need a proper crypto book - this has all been solved
before,
> > with a lot more rigour.
>
> Amen. I highly recommend Bruce Schneier's "Applied Cryptography" if
> you're really interested.
>
> ...dave
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>
|
|
From: Dave M. <dm...@od...> - 2003-04-15 18:31:19
|
Space Needle Exchange Program wrote: > [...] > know. But you can explain more what you meant by "RSA's minimum > message length is the length of the modulus"? Here's a concise description of the algorithm. http://www.pvv.ntnu.no/~asgaut/crypto/thesis/node18.html. In step 4, you can see that the ciphertext is going to be a number between 0 and PQ, the modulus. For secure moduli sizes, (512 bits for security against a college student with access to a campus full of computers) this is a pretty large overhead, which is why products like PGP use public key algorithms only to transport keys for symmetric algorithms. 256 bits is a really low number for RSA. It's about an 80 digit number which could be factored probably in a couple of days by someone who had access to just a few decent computers. Honestly, you should forget about all of this. You'll get it wrong. This is not a statement about your coding skills, because EVERYONE gets it wrong. Security is a REALLY hard problem to solve correctly, and you've got just about the hardest case there is. (P2P, no authoritative server, minimal precommunication between peers, full executable available to hackers, packets explicitly handed to people for man-in-the-middle attacks.) Your time is much better spent making a game that people want to hack... :) ...dave |
|
From: Space N. E. P. <SPA...@ho...> - 2003-04-15 20:35:55
|
Thanks for your help. How do people generate these really prime large numbers and relative primes, anyway? Simple brute force? Does the choice of prime numbers affect the security of the algorithm? (Does their magnitude affect the security?) I know that it's a hard problem, but I'm not using these communications as any sort of pervasive fundamental protocol in a game. The communication is important, but low frequency, and its disruption is only a nuisance - it won't allow you to access anything you're not supposed to be able to, it won't give you any powers you don't have. But like I said, it's important enough that I can't just leave it unguarded. The parameters you list below are all true, but every peer-to-peer file sharing network suffers from those same problems, and yet they continue to run. Why? If you hack, at best all you can be is uncooperative and disrupt communication in some locality and create spam. There's nothing to gain; it gets old. In other words, humor me and let me follow this mostly academic pursuit. :^) snx ----- Original Message ----- From: "Dave Moore" <dm...@od...> To: <gda...@li...> Sent: Tuesday, April 15, 2003 11:31 AM Subject: Re: [Algorithms] Message signature in token ring > Space Needle Exchange Program wrote: > > > [...] > > know. But you can explain more what you meant by "RSA's minimum > > message length is the length of the modulus"? > > Here's a concise description of the algorithm. > http://www.pvv.ntnu.no/~asgaut/crypto/thesis/node18.html. In step 4, > you can see that the ciphertext is going to be a number between 0 and > PQ, the modulus. For secure moduli sizes, (512 bits for security > against a college student with access to a campus full of computers) > this is a pretty large overhead, which is why products like PGP use > public key algorithms only to transport keys for symmetric algorithms. > 256 bits is a really low number for RSA. It's about an 80 digit number > which could be factored probably in a couple of days by someone who had > access to just a few decent computers. > > Honestly, you should forget about all of this. You'll get it wrong. > This is not a statement about your coding skills, because EVERYONE gets > it wrong. Security is a REALLY hard problem to solve correctly, and > you've got just about the hardest case there is. (P2P, no authoritative > server, minimal precommunication between peers, full executable > available to hackers, packets explicitly handed to people for > man-in-the-middle attacks.) Your time is much better spent making a > game that people want to hack... :) > > ...dave > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
|
From: Dave M. <dm...@od...> - 2003-04-15 21:09:08
|
Space Needle Exchange Program wrote: > How do people generate these really prime large numbers and relative > primes, anyway? Simple brute force? Does the choice of prime numbers > affect the security of the algorithm? (Does their magnitude affect Typically, you generate a very large, random, odd number, and add 2 to it until you find a pseudoprime. There's information on the Rabin-Miller pseudoprimality test at http://mathworld.wolfram.com/Rabin-MillerStrongPseudoprimeTest.html. "Applied Cryptography" is going to be a necessary resource as well, it has all the latest info on the properties of the primes that you want, but the short version is: "the bigger, the better." ...dave |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X