RE: [Algorithms] Message signature in token ring

[Tony C. <to...@mi...>]

>>You're not qualified to verify, prove, proof, or otherwise validate
>>that it implements the algorithm correctly and *securely* either.
>
>Which is completely irrelevant.  The point is that SOMEONE is
>qualified, and if that code is not available for review, then NO ONE
>except the people that wrote it in the first place are going to even
>have that option.
=20
But that someone is unlikely to be a game developer. Pick code which has =
been reviewed by someone qualified rather than rolling you own.

>The best, non-crypto example of this is DirectPlay, which is pretty
>much laughed at by most serious network game programmers I know, is a
>complete nightmare when porting to non-Microsoft platforms, and which
>is generally only defended by the people that worked on it,
=20
I'm not sure where this turned into a DirectPlay discussion. Your =
comments are highly inaccurate - and I suspect your knowledge of =
DirectPlay is circa DirectX 6 at best. Please feel free to contact me =
off-list if you would like to be educated. No hand-waving, and concrete =
examples guaranteed.
=20
>>My major point was not to roll your own unless you absolutely have
>>to.
>
>It's pretty clear you can go both ways on this issue.  I cannot
>recommend hardware mixing in DirectSound to anyone, yet it seems that
>it is often suggested as the right thing to do because, hey, "they"
>are going to get it right more often than the lowly game programmer.
=20
Haha, that's funny. If you have a modern sound card, software mixing =
makes about as much sense as software rendering. Your experience is =
clearly dated. Still, I guess you're not writing for the leading edge =
any more, Brian.

>The problem, again, is who says it's "perfect good"?  Shall we do a
>laundry list of Windows APIs that flat out have historically just
>sucked?  To be fair, we can also include the CRTL and Unix APIs if
>you'd like, the point being that just because something is "standard"
>or part of the operating system does not automatically make it good
>or better than rolling your own solution.

The point is that standard and widely used libraries tend to get the =
bugs wrung out of them eventually. They are never perfect, of course, =
but they tend to be more robust than homebrew. In the particular case of =
the Crypto API, given the level of scrutiny it undergoes both =
internally, and by a vast number of corporate customers (many of whom =
will have source code licenses), I would be highly surprised if there =
were any truly massive flaws, and absolutely dumbfounded if the overall =
quality were below homebrew solutions thrown together by people who have =
to ask basic number theory questions on a gamedev list...

>>library deficient. That doesn't invalidate the sense of using the
>>provided libraries on Windows if you are not deploying on PS2.
>
>IF there is a high likelihood that the Windows implementation is
>better than your own attempts and IF you don't care about portability
>to other systems (Linux dedicated servers; Sun Ultra clusters; etc.)
>then sure, it might make sense.

There will be suitable libraries for Unix type systems, I am sure. I =
never mentioned Windows explicitly - that was someone else. I was merely =
pointing out the general desirability of using standard libraries rather =
than homebrew, particularly where security is involved. I don't really =
see why that's a controversial observation (apart from the obvious =
challenge to the machismo of some die-hard Not Invented Here types).

- Tony