It began with a simple bit of laziness: I wanted a preprocessor so that I could write as if PHP had multiple return values. I'd write "return $x, $y;" in the callee, and "$a, $b = fn();" in the caller, and the preprocessor would rewrite it to valid PHP (throwing array() and list() around the appropriate expressions).
But I'm even too lazy for that. To do this right, I'd need to fully parse the PHP, so I could understand more complicated return expressions like method calls. So instead of that, I slapped together a lexer for s-expressions. They're a lot less hairy, and this is just some twisted experiment.
I was halfway through putting together a parser this evening for the lexer output, when I realized: a few years ago, I ported the metacircular evaluator from the SICP lectures into Ruby... then discovered I would need to write an s-expression parser, which you get for free with Lisp. (That project then died.) But if I finish an s-expression parser... I can port the metacircular evaluator to it and have the world's stupidest Lisp-1 implementation, i.e. it'll be done in PHP.*
Alternatively, I can define a package in SBCL that emits PHP, and have the reader and macros for free. Then my head exploded.
* Because this tool was intended for PHP shops, the compiler would have to be written in and emit PHP so there's no Scary Foreign Language involved, other than the compiler's input. And originally, that input language was going to be almost PHP.
Thursday, May 19, 2011
Tuesday, May 10, 2011
Quickie: Diffie-Hellman Groups
Relying on others' suggested magic numbers for crypto is probably a Bad Idea, so recently I studied Diffie-Hellman a while to understand what the "DH Group" parameter was in my IPSEC setup, and my PuTTY settings.
DH turns out to be a lot like RSA, so bit lengths are comparable between the two and neither is directly comparable to symmetric ciphers like AES. A specific Diffie-Hellman exchange happens using some parameters: a generator for the base, and a prime to use as modulus. (An exponent remains secret.) DH Groups refer to specific, pre-chosen prime-and-generator pairs so that, for example, SSH can negotiate "group 14" instead of transferring the complete parameters themselves.
These groups have been standardized in RFC 2409, with additional groups defined in RFC 3526. The latter RFC defines the bit lengths of the groups explicitly, stating that group 5 is 1536 bits, group 14 is 2048, and group 16 is 4096 bits. As far as I can tell, groups 1 and 2 defined in the earlier RFC are only 768 and 1024 bits, respectively.
Note well: I believe this means DH groups 1 and 2 are dangerously short and should not be used to set up an IPSEC VPN today. Likewise, PuTTY should really be configured out-of-the-box to warn about the use of anything less than DH group 14.However, before I take my own advice, I need to do some experiments to determine whether the IPSEC client in iOS actually handles DH groups other than 2. Edit from THE FUTURE: iOS 4.x does not accept other groups; iOS 5.x no longer accepts group 2, AFAICT. I haven't gotten a working IPSEC VPN set up again, though, since it's not very important to me. (Work provides a PPTP VPN.)
DH turns out to be a lot like RSA, so bit lengths are comparable between the two and neither is directly comparable to symmetric ciphers like AES. A specific Diffie-Hellman exchange happens using some parameters: a generator for the base, and a prime to use as modulus. (An exponent remains secret.) DH Groups refer to specific, pre-chosen prime-and-generator pairs so that, for example, SSH can negotiate "group 14" instead of transferring the complete parameters themselves.
These groups have been standardized in RFC 2409, with additional groups defined in RFC 3526. The latter RFC defines the bit lengths of the groups explicitly, stating that group 5 is 1536 bits, group 14 is 2048, and group 16 is 4096 bits. As far as I can tell, groups 1 and 2 defined in the earlier RFC are only 768 and 1024 bits, respectively.
Note well: I believe this means DH groups 1 and 2 are dangerously short and should not be used to set up an IPSEC VPN today. Likewise, PuTTY should really be configured out-of-the-box to warn about the use of anything less than DH group 14.
Wednesday, May 4, 2011
Quickie: The Necessity of Whimsical Names
Rackspace recently announced that they'd like to discontinue Slicehost at some point, migrate everyone to the EC2-like Rackspace Cloud, and make people worry per GB about the bandwidth they're consuming. So I'm preparing a move to Linode for more of everything*, and in the planning, I've come across a new argument in favor of whimsical names for servers.
If I give each server a whimsical name, like alice.example.com and bob.example.com, I can always refer to the old and new IP addresses as "alice" and "bob", while the change of IP of "www" propagates through the DNS. Between the time where the new address is set and the old one is expired (and note that there's no way to force an ISP's resolver to honor the TTL if they choose to assume "no TTLs will be shorter than an hour") the name being transitioned points to a more-or-less random server.
Basically, the whimsical name is like a server ID, and the service-based names are just conveniences. Though a program is three lines long, someday it must be maintained; though a server hosts one service, someday it will have to be replaced. When an organization gets big enough that it can't generate whimsy as fast as it needs servers, then it should go with something more regular for the server name, but each server should still have a unique, non-service-based name.
* Except bandwidth, but the 11% difference is smaller than my current monthly consumption, so it turns out not to matter much. Even if it did matter, that much transfer on The Cloud (insert angelic chord here) would be expensive, so Linode still wins.
If I give each server a whimsical name, like alice.example.com and bob.example.com, I can always refer to the old and new IP addresses as "alice" and "bob", while the change of IP of "www" propagates through the DNS. Between the time where the new address is set and the old one is expired (and note that there's no way to force an ISP's resolver to honor the TTL if they choose to assume "no TTLs will be shorter than an hour") the name being transitioned points to a more-or-less random server.
Basically, the whimsical name is like a server ID, and the service-based names are just conveniences. Though a program is three lines long, someday it must be maintained; though a server hosts one service, someday it will have to be replaced. When an organization gets big enough that it can't generate whimsy as fast as it needs servers, then it should go with something more regular for the server name, but each server should still have a unique, non-service-based name.
* Except bandwidth, but the 11% difference is smaller than my current monthly consumption, so it turns out not to matter much. Even if it did matter, that much transfer on The Cloud (insert angelic chord here) would be expensive, so Linode still wins.
Subscribe to:
Posts (Atom)