I'm sure the world will be shocked to learn that Microsoft's implementation of protecting Excel worksheets and workbooks may be... uhh... lacking in security. I needed to make a modification to a protected workbook (for extremely practical and entirely wholesome reasons), so I figured that I would see what it would take to figure out or find the password. Well not much, it turns out. I viewed the document using "less" in a terminal and near the end (always look there first) there's a section of code-like string fragments having to do with protecting and unprotecting, and nestled nearby was a short string that didn't make sense as code, didn't make sense as any kind of Excel keyword, and was not contained in the visible Excel workbook text.
So I tried unprotecting the workbook with that string as the password. Yep, that did it. Now I'm sure it was implemented that way so that the average human who forgets a password ten minutes after thinking it up wouldn't be completely stuck. But those kinds of "failsafes" are usually just wide open back doors. Definitely the case here.
No doubt thousands of other people figured this out long ago, but it was amusing to me.
In light of all the "security" being implemented by the current administration, we ought to all grab Gizmo and Zfone and use them whenever possible. Gizmo is an IM-like VoIP (i.e. real VoIP using SIP, RTP, etc.) client and Zfone is Phil Zimmerman's (think PGP) contribution to VoIP security. It embeds strong crypto in the RTP stream directly, bypassing any filters or blocking at higher layers.
So I did a little analysis of an encrypted iChat session (tcpdump is your friend). Looks to me like they're doing a public key encrypt on each message. More specifically, I think they're encrypting a random session key for each message, and then encrypting the message with the session key, using a block cipher having large-ish blocks, so I suspect it's AES. That would be both the logical, good choice and would fit my guess based on message size differences. There's a momentary lag when sending each message, which would also support the notion that they're public-key encrypting each message in some way (that and the message size and the presence of certificate-like text). Interesting stuff.