scienceferret

There is also the NeHe OpenGL tutorials. OpenGL means Open Graphics Library, and it does a lot more than just 16 colors. In fact it's the industry standard for game graphics, so you might want to check it out. It's a little weird, but you'll note each tutorial is available in one of many languages. Which language you use isn't as important as what algorithm you use.

The hash itself is the resource identifier. I could control the resource by specifying which hash I want to receive, and checking what I received on arrival to make sure it matches with the same hash. Nobody can change what resource is available for a given hash.

Well IRC for one. But why would anything non-proprietary need to be non-XMPP? There's a strong impetus for open protocols to standardize, and I sure haven't seen any better ideas than XMPP for throwing stuff around. I thought you meant the proprietary ones though, of which there is an embarassment of presence notification. When did I say I was talking about an "instant" messaging system? Google Wave is a delayed, high latency messaging system, like email. OTR doesn't work on that, as it requires low latency interaction to set up a session. What does solve the problem is this little thing called PGP. It solves the problem poorly though, not signing things like the "Subject" or the "external references". Google could have fixed the issues of PGP making a revolutonary content distribution network, but instead they just... turned email into XML, not adding on any security or authenticity. Sure I could use PGP over Google Wave, but I could also use PGP over email and it would work just as well, so why not just use email? Wave doesn't add anything to that.

Now hold on a second. You claim that it negates all benefits, but how would such a replay attack operate? Supposing I had the following hash tree: A->B,C,D B->E,F C->G,H D->I,J S(A) ...with the leaf pieces (E-J) being the actual data, and I only signed hash A. How would someone execute a replay attack when you were trying to get those pieces from some sort of distributed hash table? Supposing someone tried to "replay" sending you the signature for hash A. But you've already got the signature, and it won't prompt you to re-download any of the lower pieces. Supposing someone tried to send you piece D twice. You would reject the second time since you already have piece D. If they sent you an unknown hash with the contents falsely as piece D, not only would I be able to discard that piece, you could mark that peer as bogus.

It is most certainly not, in the most common cases. Take the common case of two people communicating via two different jabber servers. Instead of encrypting your message for your recepient, you encrypt the message for your jabber server. It decrypts the message then, if you're lucky, and 90% of the time you're not, it re-encrypts the message, not for the intended recepient, but for the second jabber server. The second jabber server does encrypt it to the recepient, after decrypting it, and delivers it quite neatly. When each step in a series of delivery steps de-crypts then re-encrypts what they're delivering, that's called point-to-point encryption. End-to-end encryption, there is theoretical support for it in jabber, but mostly people just use... uh OTR. I doubt that would work well for Google Wave though. The thing is, I could PGP encrypt and armor my message, send it to a friend, and it'd be TLS encrypted through all those XMPP Wave servers, but I wouldn't care about that, because even if I sent it plaintext in email, it would still be PGP encrypted armored data. So PGP comes closer to being a solution to the problem of message security in transport, while Google Wave just becomes a slight improvement on email, that encrypts and decrypts things several times for no apparant purpose at all. Well I'd propose some kind of trust network, or some sort of decentralized credits system, where people could establish trust relationships with each other, and thereby avoid many of the risks that come from impostors or ne'er do wells. PKI is just putting a lock on the henhouse and giving the key to the wolf. Because... PKI works, and works well, only if the certificate authority is trustworthy. The longer said authority is trustworthy, and the more ubiquitous this ultimate trust hierarchy becomes, the more damage will be done when that trust is broken. Compare that with a trust network, where as time passes, and ubiquitousness increases, the risk of total single point system collapse does not go up. So the fact PKI is ubiquitous is a weak point, because that makes certificate authorities a more attractive target for corruption, manipulation, and dirty dealings. And the fact that it works, and works well, belies the fact that it works well... for now. Say, how's that Federal Reserve PKI been doing lately? Unlike PKI, I don't wish fondly that TCP were relegated to a previous era. I'm not a big fan of C anyway. Uh, every popular messaging system has presence. As for pubsub, I think it's a lot more complex a problem deciding who can publish what and who can subscribe to what, than the actual mechanism of publishing and subscribing. The decision of what goes where and who gets what is the big problem, so the fact that XMPP has XML stanzas you can use to describe such a hypothetical, unimplemented publish/subscribe exchange doesn't seem like a big advantage to me. But I don't work with XMPP on a daily basis, so it's quite possible that I'm missing something. I agree XMPP is pretty neat. It goes one step beyond HTTP allowing for a bidirectional exchange of streams of XML stanzas, instead of just a simple request/response, or pipeline that HTTP supports. It just doesn't solve the problem of how to make sure you're talking with people you can trust, and it doesn't solve the problem of making sure people you don't trust can't mess with the information you give out. I don't want to have to trust google.com in order to discuss something privately with my friend, or circle of friends. I only want to trust them. The requirement that I trust google.com, and that I trust Thawte Consulting Inc. to tell me who gets to be google.com, and that I trust the USA government to keep both Thawte and Google from messing with me or my friends, those requirements make Google Wave seem less amazing to me than I would otherwise think. Sure I could make my own Wave server (maybe) but you know 99% of the people on it would be using Google, so I'd be SOL to avoid trusting them, or trusting some other giant faceless authority. How am I supposed to meet Google for coffee at a roadside cafe? Yeah...

If you deliver a signed hash tree, someone else can replay that signed hash tree, just as if you delivered a signed root hash (which is the hash of a hash tree). So you couldn't use such a system to vote, for instance, because someone would replay their supporter's vote to everyone they could reach. I really don't think replay attacks are of much worry here anyway. The worst replay attack that could happen is you examine a signature that is valid and your friend's signature, but then you realize that you've already processed the piece with this hash, so you do nothing. Adding a timestamp would prevent that, but then you'd have to remember timestamps, so it might be more trouble than its worth. Seriously. What could someone do to mess up such a signature via replaying? Signing a hash of some representation of the hash tree, is just as reliable as signing the root hash of the hash tree.

Yes, that's why I suggested Gnutella as one possible way to send messages around. It uses a hash tree to divvy up files, Im pretty sure. The signing however would only need to be done on the root hash of this hash tree. That's why I specified also signing the date, or some sort of timestamp. Once you've seen it, you can mark it as played already. All you'd do is request the correct message once over again though, if you were tricked into replaying. I'm no expert at cryptographic signing, and I'm sure whatever tool I used to formally do it would handle the matter far more comprehensively than just me writing s-expressions into the text box here. It wouldn't be any different from a normal signature, except you could verify its signer before downloading the file. You would still have to download the file to verify that the file's contents match the hash of course. ergo hash trees, etc.

Hmm, perhaps then if the hash were accompanied by some known standard value. So like (encrypt "magic-hash" hash todaysdate) would be verifiable since decrypting it with their public key reveals something starting with "magic-hash". Or maybe (combine salt (encrypt salt hash date)) so it wouldn't need to always be the same magic value.

TLS is point-to-point though, not end-to-end, and it only uses the SSL certificate hierarchy, which is quite archaic IMO. XMPP does have some promise, but only if it employs the technologies that actually work. Otherwise, it's just an empty envelope.

Hey, you know how with PGP, the contents of the email are hashed, and then the hash is signed, and the signed hash is appended at the end of the email? That can be a lot of trouble, for large emails! You could be receiving a 50 megabyte email but you would be unable to tell that it was corrupted or not from someone you trust, until you had downloaded the whole entire email. What if you sent the signature part separate from the email? It contains the hash, encrypted with the sender's private key (and only decryptable with the sender's public key). Couldn't the recepient verify that signature, without having the 50 megabyte email at all? Sure you would only have the hash, not the actual message, but it would verify with the correct key, so you could see who was trying to message you. Now suppose you do something silly like put your message up for download on the Gnutella network. Couldn't you only sign the SHA1 hash used by the network to identify your message? Then your recepient would only have to receive an email containing that hash encrypted with your private key. By decrypting it with your public key, they could tell it was from you, and by then searching for that file via hash on the network, they could be sure they were getting the right file. Of course the file could still be corrupted, but the network has a lot of safeguards to prevent a file that does not match its hash from propogating, and of course you'd verify the hash yourself on receiving the file. Seems like a lot of trouble, but then so is having to blindly trust (or blindly distrust) all large emails, until you can actually get the signature. I realized how much of a problem this was when trying to write myself a mailing list. The From: address can be set arbitrarily to just anything, so it can't be used to authenticate members, but PGP you have to get the whole email first, thus making it easier to flood my service. Maybe it'd be a good strategy to resort to once the message gets beyond a certain size?

It's really too bad we can't figure out how to stop bacterial infections, and how to stop the body from rejecting foreign objects, because those are the two biggest reasons why we can't just stick an antenna into our skulls. If we figured out how to get around those two things, I think society would indeed resemble GitS most uncannily...

How do you use the 3D image in C code, when the image is just in a file? If you already have it working like Load("3DImage.3d.thing") then what you can do is base64 encode the data in that file, make an object with an array just {char 3d_image[] = "..."} where the base64 data is in the .... Then just use a base64 decoding library to turn it back into the original bytes of the file, instead of opening an external file and loading the bytes from it.

I'm not that impressed with Google Wave. Despite important technologies like one-way hashing, secure signing, and end-to-end encryption, Google chose to ignore all that and create nothing more than a pretty user interface to a shaky, archaic underlying implementation. But thanks for offering!