Encryption, Databases, TED, OAuth/OpenID spoof, E-mail security, Secure workstation

Post date: Nov 18, 2012 1:31:32 PM

  • Reminded myself about plain paper and pen ciphers which you can utilize without computers. Like the running key cipher (aka auto-key cipher) and The Playfair cipher. Naturally these won't provide strong encryption, but still might be required at some times when encryption is a must and there isn't proper hardware / software to get it done. I would like to see someone cracking Playfair ciphered message with plain paper and pen. Playfair can be also be expanded to two-square and four-square ciphers to make it stronger. Auto-key cipher can be used easily as code-book and with proper OTP keys it becomes impossible to break, if we just can assume you have strong shared random one-time pad (OTP) key source to be used with it. VIC Cipher was used during Cold War by Russians. Solitaire cipher is also quite interesting. Don't forget Trifid cipher. Also check out this link. Most importantly if you use substitution, fractination and transposition, it becomes quite hard to decipher (without the key(s)) that manually.
  • Studied several countries and state of economic and political freedom as well as self-sufficiency and sustainability. I got in to this topic when I watched (in background) documentary about strategic relocation.
  • Studied basics of Intel Xeon Phi coprocessor.
  • Studied fully homomorfic encryption, great idea, just utterly unpractical, but maybe it'll break through in future.
  • Refreshed my memory about more advanced disk encryption modes like: XEX, XTS, EAX, LRW, EAX and GCM modes. My OTR emplementation uses OFB which isn't recommeded, but in situations where message isn't much longer than the key, it should be secure enough. Naturally key entropy is very important in all cases.
  • Here's nice article about encryption, well I have to say that in case of OTR implementation, I'm not trying to actually validate the data from database to check if it's being tampered. I'm configrming that user has provided right encryption key. I also don't want to reveal any information about the message content, so I MAC message before encrypting it. This shouldn't be a problem, because possible attacker can't provide encrypted data, all data processed by application is encrypted by itself.
  • Had some fun with traditional data transfer methods. Now my integration API can handle without any problems plain FTP, FTPS (implict) and FTPES (explict) which is the standard RFC4217. Yeah, naturally certificates are checked properly, it would be bad to fail that check. Also client certificates are supported.
  • Studied CodernityDB and it worked very well in my tests, and it was fun to play with. I still wouldn't use it in production.
  • Studied UUID types and usability and performance issues related to using UUIDs as primary key in database. Many databases just do not perform too well when using UUIDs as primary key. Why not to use int with auto-increment? Well, that auto-increment function requires locking and might become bottleneck it self when there are large number of parallel insterst being done.
  • read: Check Point Whitepaper DoS Attacks: Response Planning and Mitigation - Nothing new. ;(
  • Refreshed my memory about: Do not track (DNT). Utterly useless, it seems that nobody really cares about this.
  • Watched 9 TED talks, nice stuff: Playlist by Mikko Hyppönen 9 talks about tech ... and fish.
  • Checked out Google+ REST API including History API and tried Python Google+ API library. Very easy to use, but as long as basic REST API is read-only, it's quite useless.
  • After taking a look how users use OAuth and OpenID. I'm sure that OAuth spoofing could become real problem. As we all know, users do not really know what they're doing, so they might easily give credentials to fake page which just does look real enough. This is exactly why we need authentication which also authenticates the site to the user, it's not enough that user is authenticated to site. All Finnish online bank payment systems suffer from this problem. Basically it's really bad idea to redirect user to login page, because user most probably does not properly verify that the login page is real. If it wouldn't upset people too much, it would be just fun to setup fake pages and see if anyone accidentially gives credentials even if traffic isn't even being harvested by redirecting it from other sites. Of course in the cases DNS is being managed by organisation it's easy to DNS hijack for all interesting sites. If it wouldn't be in black sector it would be just interesting to see what would happen. Just like the researchers did who registered misspelled domain names to harvest confidential email.
    • Anyway, this is very common issue. Finnish banks got it, 2G / 3G mobile networks got it, etc. So when security layer was designed, all they cared is user authentication, but they forgot that network/service should be first authenticated to user. Especially if direct shared keys are used, which aren't derived on data being authenticated.
  • Nice article: How to keep your e-mails secret ... It got many excellent points, this is just why I run my own servers and actually emails which are private are sent only as read links, message content and data remain only on my server in encrypted form and are overwritten and deleted after 30 days, even if being unread. In situation where someone stored that message with link, they don't have my message body at all. I know this isn't perfect solution, but it's much better than what many services provide. It's also quite user friendly after all. Based on required security level, password, user login with optional TOTP authentication might be required, before message can be read. But in most cases, sending link wihtout password is enough, it prevents systemic storing of messages by GMail or Facebook. System naturally allows attachments and got reply feature so people without account can reply securely.
    • For some uses running your own Tor hidden service is fine, it's quite easy to run if you're familiar with Tor and services. You can also use something better and more secure for communication than plain HTTPS and Tor, like SSH and BBS like interface. In many cases using browser could be a security risk, even with Tor. That's why SSH is better, SSH allows also an option to use client certificates, ok ok, HTTPS makes it also possible but do you know anyone using client certs with HTTPS? Using SSH reduces risk that people accessing your service with systems which aren't properly prepared to be secure won't store anything at all on disk. (Yes, it still could be possible to swap or hibernate some data if users are major failures.)
    • Yet another option which I especially like is RetroShare, it's secure and keeps data private, but it doesn't inherently hide connections and traffic between nodes, for that part you'll need another anonymization layer.
  • For highly confidential communication additional GnuPG encryption layer is used, and encrypted data is moved using serial cable to secure work station for processing. Secure workstation isn't connected to internet at all. It's only used to decrypt, process (read/write) and encrypt secure messages.
  • Just for funr I wrote my own Python app, which allows my to use PyECC to use ECC-512 key pair, which is then used in front of PySkein / Threefish-1024 to encrypt / decrypt payload data. Yes, I know there are very many ways to fail and make this insecure, so it's not being used. But I got just fun out of doing it. At least it works well on basic level.