The term "network neutrality" is mentioned very often lately; also in the context of FCC ruling, such as here, and here. Since the definition of net neutrality is not always clear, this topic is not subject to as much public debate as it probably should. Here is my take of what network neutrality is, and why it is difficult to regulate and enforce. I will start with my proposed technical and service-related definition of "network neutrality", and will follow with a brief explanation of why this is both difficult and important.
It has been a while since the announcement of the demise of TrueCrypt (which I reported), and an equivalent replacement for all those people who rely on it is not yet evident. TrueCrypt did not revive yet, but the situation is not time-wise critical as it may have seemed. There are a few options, for the time being.
I wish I knew where TrueCrypt stands now, but I don't. I follow TrueCrypt and regularly endorse it ever since I discovered it and wrote this post nine years ago. TrueCrypt was, and may still be, the most sensible and presumably-secure volume and full-disk encryption software for Windows; also supporting Linux and Mac. A few days ago the project discontinued, and users were directed to alternative, non-open-source solutions.
A few days ago, a critical bug was found in the common OpenSSL library. OpenSSL is the library that implements the common SSL and TLS security protocols. These protocols facilitate the encrypted tunnel feature that secure services -- over the web and otherwise -- utilize to encrypt the traffic between the client (user) and the server.
The discovery of such a security bug is a big deal. Not only that OpenSSL is very common, but the bug that was found is one that can be readily exploited remotely without any privilege on the attacker's side. Also, the outcome of the attack that is made possible is devastating. Exploiting the bug allows an attacker to obtain internal information, in the form of memory contents, from the attacked server or client. This memory space that the attacker can obtain a copy of can contain just about everything. Almost.
There are many essays and posts about the "everything" that could be lost, so I will take the optimistic side and dedicate this post to the "almost". As opposed to with other serious attacks, at least the leak is not complete and can be quantified, and the attack is not persistent.
When people discuss Bitcoin, one of its properties that is often considered is its presumable anonymity. In this respect, it is often compared to cash. However, it shall be recognized and understood that Bitcoin is not as anonymous as cash; far from it, actually. Its anonymity relies on the concept of pseudonyms, which delivers some (unjustified) sense of anonymity, but very weak anonymity in practice.
I recently got a US patent application granted by the Patent and Trademark Office. The patent bears the title "Methods Circuits Devices and Systems for Provisioning of Cryptographic Data to One or More Electronic Devices".
I attended CyberTech 2014 on January 27th-28th. CyberTech is a respectable conference for technologies related to cyber-security. The conference consisted of lectures and an exhibition. The lectures were most given by top notch speakers from the security space, both from the public sector and from the private sector; most being highly ranked executives. The exhibition sported companies ranging from the largest conglomerates as IBM and Microsoft, to garage start-ups.
I am easy to disappoint by cyber-security conferences. Simply put, there are more cyber-security conferences than what the security industry really has to say. This implies that for the security architect or practitioner, most cyber-security conferences lack sufficient substance. I take CyberTech 2014 with mixed emotions too. The exhibition showed interesting ideas, especially by start-ups, while the lectures left more to wish for.