Data compression, hashing, file systems, web casts, networking, cloud hosting, networking etc...

Post date: Jan 22, 2012 6:26:13 PM

I have been studying every day, several hours a day. Study subjects like:

• Encryption & Hashing: Threefish, OCB mode, Skein, Jenkins, Pearson - Nice article about hashing
• Compression: LZ77, LZMA2, LZMA, Huffman, Burrows Wheeler
• File system: Refreshed my memory about BtrFS and it's latest development
• Cloud hosting: IBM SmartCloud, I also tried Nodester - Didn't like it, beacause I'm not familiar enough with JavaScript
• Web casts: Risky Business and plenty of stuff from TED
• Networking: DCCP, ECN, NAT66 / NPT66, shim6, IPv6 multihoming using NAT without BGP.
  • World IPv6 launch is here!
  • IPv6 + NAT, please no! NAT breaks Internet connectivity!
  • SCTP: At least for my apps SCTP would be far superior compared to TCP and also would make communication faster. Packets also can be received out of order if order doesn't matter further saving bandwidth. If ECN (removes packet loss) is used with SCTP it's real killer solution compared to plain old TCP. Less data to be sent faster and more reliable delivery. SCTP keeps message boundaries clear and allows multiple parallel streams with one negotiation. TCP's sliding window adds overhead by delivering partial messages. Also SCTP uses CRC32 instead of CRC16. I have experienced issues with bad links and huge files while using TCP, received file / data is simply corrupted. Not completely, but even one corrupted block is enough to completely destroy compressed file.
• Reading: Good to know about data security and Google. Good to know information in easy to understand package. - I really recommend reading this.
• Other stuff: Squid cache eviction algorithms and configuration parameters, more SaaS and Virtualization stuff, Magnet URI scheme
• Writings: I wrote long article about two factor authentication (2FA) and practical ways to implement it. I recommended that the authorization key should be directly related to the transaction being confirmed. Using OTP passwords without payload parameters is just bad design. In those cases user does not know what they're actually confirming. Any MITM or Trojan could modify messages in real-time. So tokens aren't good solution, SMS messages with enough information to confirm transaction and single use code for that is pretty good. But we shouldn't forget that there are many technical and not so technical ways to attack that implementation too. GSM/2G networks aren't so secure, if attacker got high value target. Also phone software could be modified and can be rogue applications or whole operating system can be replaced to further deceive user.

I couldn't list everything, but that's small part of stuff I have done. There is also long rant coming about Yahoo Mail, listing all the dirty facts.