saladwithsteve
Thursday, December 12
My pal Darius Bacon is having a holiday sale and has put up some real literary (and computer science) treasures for sale. 15:59#
Tuesday I released pre-documentation for Blogger API 2.0 and in that documentation I mentioned a 'token' element to the Login struct which would have some amorphous "security" property. I then later dismissed the token element on the bloggerDev list as something I wouldn't be able to finish because I didn't define a threat model, wasn't happy with the work I had completed on the subject, and felt that it would need retooling of the return types to make it effective. I've changed my mind on that last point (no retooling of return types is necessary), which made me think of a threat model and then flesh out how protection against that threat might possibly work. Here we go:
Threat Model: Protect against somebody sniffing a user's password over unprotected XML-RPC traffic.
There'd be a module called blogger2.secure with a method named handshake(). It doesn't actually return a value, it initiates two DH key exchanges, so you now have two shared secrets. The first secret is used to hash the password and that new value is sent across the wire as the 'token' field in the Login struct. The second secret is then used to hash the first secret and the original first hash is now stored in the second field. Everytime you send a token, this happens again. This makes the authentication perfectly forward secret. I'm pretty tired so I might have missed something there.
There is one problem I forsee; what if by network failure or some other problem the two secrets become out of sync and the server no longer accepts "legitimate" (to the client) tokens from the client? You could just re-handshake() although you would want to know that the password was legitimate and this wasn't the reason for the token rejection. This brings up another point; when you send the initial handshake request; how does the server know who to associate these shared secrets with and how does it authenticate who that person is originally? Did I just make a house of cards?
I'm posting this here rather than the bloggerDev list because I'd like some opinions from people who aren't necessarily on the bloggerDev list. The question of original authentication is key and I'm sure it's been solved before. PFS isn't new, I bet I'm just missing something.
Update: I now see how it's possible to do initial authentication using another DH exchange and then sending across username/password with that first shared secret. -smj (2:30am). 02:14#
Monday, December 9
Another Java paper: Sorry, I do program in it for a living after all. This one makes some really good points; one point in particular debunks the myth that ints are 32-bits wide in the JVM. Language lawyers will argue (and win) that ints are only specified within a range and that the JLS doesn't specify how wide an int is in the JVM but merely that the number can't be larger than 2147483648 (2^31) and therefore an int could be any width inside the VM. This paper also clarifies what a 'critical' section of code really is as opposed to what people usually call 'critical' sections of code.
[via Brandon Lee] 23:59#
Dagnabbit, Wiseman scooped me on the Weinreb post:
Daniel Weinreb on Symbolics' decision to buy instead of build the keys for their keyboards:[via lemonodor originally from ll1-discuss] 23:42#We made our own monitor electronics, our own laser-printer electronics, we wrote the microcode, we wrote the operating system, and so on, but making our own keys was, finally, below the level of abstraction that demarked our build/buy line. We were really, really crazy, but we were not really, really, really, really crazy.
Java has needed Generics for a long while now and 1.5 will get them according to this article [via just looking]
Here's a nice little example of what you can do with XUL. It's useful to note that the Mozilla browser interface is itself written in XUL and Mozilla Themes are commonly written by copying the main Theme, modifying that template's XUL, CSS, JavaScript, and images then repackaging it into a new jar file.
Also, I read the beta chapter on Servlets from O'reilly's upcoming Java Enterprise Best Practices. Not too bad, even for an Enterprise book. 12:58#
Thursday, December 5
Even though I'm not a Linux Kernel hacker I really enjoy KernelTrap's articles. This week they interview Ingo Molnar about his recent work on the O(1) scheduler in the 2.5 kernel and his history with the kernel. He makes a few comments on the BitKeeper controversy. 16:07#
Monday, December 2
Joseph on about Libertarianism: Beware of beautiful philosophies of principal that are selectively cited in practice.
I'm not sure how Joseph stands on the subject, although he gets very close to stating his opinion, but I firmly believe that the Free Market Fantasy is one of the most dangerous concepts in play currently and the amount of airtime that this painful double-standard gets in Libertarian circles is the main reason I'm not one any longer. 18:27#