Sanity of Cipher Creation Argument

Many conservative cryptographers have argued against making your own ciphers and to only use well known ciphers from cryptographic libraries to do real world encryption. I would not deny the above fact. It is true that creating a cipher unbreakable by oneself is easy due to self-biasness towards one's own ciphers. there are a lot of good ciphers that have been well studied and proven to be secure out there to be used for one's real world applications of data security.

The above statement is true if you are attempting to use a cipher for real world data security application. If your intentions of designing a cipher is for the sake of experimentation and learning more on cryptography, I would personally say it is indeed a good idea that every cryptographer-wannabe or anyone trying to learn cryptography should at least try their hands on designing themselves a cipher to demonstrate the amount of understanding they have learned so far regarding the topics of cryptography.

Bruce Schneier mentions in his blogs and books that the best way an amateur or wannabe cryptographer should begin learning cryptography is to attempt to break someone else's cipher. I would partially agree with Schneier that breaking existing ciphers and protocols are good ways to start learning cryptography. I would personally like to add on that a "newbie" should learn and demonstrate his understanding of cryptography by attempting to create a cipher for fun and attempt to break his own works. The reason I think creating and breaking one's own ciphers should be placed on equal importance with the breaking of other people's ciphers is because you created your own cipher and you should be able to understand how your own cipher work much better than someone who attempts to review your cipher. If you are trying to review someone else ciphers, you need to understand their attempts to express the mechanics of their ciphers in their white papers and not all of these white papers contain clear and concise explanations on the designs of their own ciphers. Some of the white papers simply have a chunk of formula and a "newbie" is expected to quickly grasp at these esoteric looking formulas and try to perform a cryptanalysis on the cipher. Even among expert cryptographers, they may not fully understand each other's papers and may have to communicate among themselves to enquire about the mechanics of other's ciphers. I personally feel that the option of creating a fun cipher for cryptanalysis should be one of the basics of learning cryptography and who doesn't like to have some fun making their own ciphers ?

Kill switch your smartphone

Read:

• http://www.wired.com/2014/04/kill-switch/

Kill switches are originally intended for use as a remote method of wiping data off a smart device remotely. But history has shown that if you have a kill switch installed, if discovered by hostile parties can be used against you. If an attacker manages to find a way to send the correct command to activate the kill switch, it might disrupt or even endanger whomever owns this kill switch (imagine if you were to plant a remote kill switch into smart devices and these smart devices have some sort of link to life support systems for health patients, that would be really dangerous).

Remote wiping implementations are not so straightforward in it's designs and implementations. One have to consider the fields of economics, politics, social behaviours and most importantly, the technical side of computer security.

Relating to the technical side of computer security, some remote wipe providers may offer some form of strong symmetric key or PKI infrastructure to encrypt the communication between your smart phone and the remote command tool to send the kill signal, but what is going to protect these encryption keys or passwords from falling into the wrong hands ?

Once you have given someone the access to remotely send commands to your own system, you have effectively lost control over your system. That is the basis of computer security: which is to secure your system and prevent yourself from losing control.

For the economical, social and political side of matters, who truely owns the smart device ? Is the person who bought and signed the contract for the smart device the true owner of the device ? Are there political motivations for inserting political and governmental backdoors via the remote kill switch ? Are the service providers and software providers trying to gather more user data some mechanism in the remote kill switch for their own benefits ? There are much more to consider than the outright "benefit" of simply remote wiping your smart devices if it lands in the wrong hands.

Who would know if some malicious employees or someone within the the company or organization whom you have given remote wipe command access to might not intentionally or accidentally wipe your smart device or use the security loophole(s) of the remote kill switch to remote control your smart device ?

An alternative to using a blackbox style remote kill switch which you have no access or control over the source codes and mechanisms is to look for open source alternatives which you can review the source codes to ensure that there are no backdoors in the remote kill switch and the mechanisms in place to transfer the command to remotely kill a device is sent our via secure and conscious means. The problem with such an open source implementation is not everyone knows about computer security and how to evaluate codes to ensure that the codes and kill switch mechanics are safe. People are likely to simply purchase or subscribe to a kill switch without proper inspection and trust it which can be detrimental to one's own privacy and security.

In essence, deliberately introducing a loophole (remote kill switches are considered a deliberate loophole in CS field) into a system degrades it's overall security regardless of the intention or purpose.

Here are a few tips to secure your smart devices:

• Never leave them on the table or chair or leave them unattended even for a few minutes if these devices contain personal data (phone contacts, email, address book, PIN managers, bank transaction applications ... etc).
• Filesystem / Volume encryption.
• Always use a Password Manager with a Master Password and never write them down on paper or Notepad.
• Never share passwords.

Afterall, the best device security is yourself being cautious and aware of the surrounding. Depending on some loophole technology to remote kill your device is the worse idea.

What would have prevented Heartbleed

We all know the potential damage Heartbleed could have caused. So, what are the solutions that could have mitigated or prevented it in the first place.

I would attempt to rank what I feel is important for a security setup to protect it's keys.

1. PROPER AND SECURE CODING PRACTICE WITH PROPER CODE REVIEWS!
   
2. Use programming languages that will help lessen confusion and mistakes like these.
   
3. Ensure that cryptographic libraries should be doing what they are suppose to do ! Cryptography is a hard subject and not everyone is good at this subject but everyone wants to use Cryptography to protect their digital assets. An application programmer who uses a particular cryptographic library may not properly understand encryption so it's hard to proof if the library is stable and "sane".
   
4. Basic education on Cryptography to CS/IT/BIS students should be made mandatory due to the wide spread use of Cryptography in modern computing.
   
5. Key handling to be performed somewhere else. Segregate the system into layers and sandbox. If one part is compromised, you have other layers to support and maintain a certain level of security.
   
6. Integrate a FIPS-140-2 Level 3 or higher installation of  Hardware Security Module (HSM) to solely handle the keys. Keys should always be handled in a HSM with FIPS-140-2 Level 3 or higher environment whereby the keys will never leave the secure environment and the HSM should be in working condition clean of no recent tamper events. Not everyone can afford a FIPS-140-2 Level 3 or higher HSM so it's pretty much a luxury item for those who can afford them. For those who can afford these HSMs, they should be using them properly.

If you noticed, proper education and secure coding has been ranked on top of everything else. The reason is due to the fact that, no matter how good the libraries and hardware/software are, proper understanding and usage is the key to security. Most of the standard algorithms out there that are well known are usually secure. It is the mismanagement on the human aspect that is causing so much security problems.

Should I still use OpenSSL

OpenSSL does not have a good record of secure coding although they patch their codes very quickly. The most recent Heartbleed bug allows users to access the memory space (which also includes the keys loaded in the memory) from a direct connection to any application running the affected versions of OpenSSL.

• Hearbleed Bug:   http://heartbleed.com
• OpenSSL CVE: http://www.openssl.org/news/vulnerabilities.html

What should you turn to next if you decide to drop OpenSSL from the list of SSL cryptographic providers? You might want to try out Mozilla's NSS and use the NSS to replace the leaky OpenSSL library.

Theoretical Insecurity of Bittorrent Sync

Bittorrent Sync (BTSync) is a new product created by Bittorrent company (whom also brought us the Bittorrent technology) for syncing your data between multiple endpoints or parties while leveraging the Bittorrent network and technology.

The product is a closed source product so all I can analyse is via the published details on their website.

I have not found time to sit down and try out the software and would not entrust my personal files to a closed source product to distribute them across the Internet for syncing therefore I may not have the most accurate picture of it's underlying protocol.

The BTSync technology claims to be "very secure" and here are the theoretical weaknesses that increases my discomfort and unwillingness to try it.

According to the Technology page of the BTSync product (bittorrent.com/sync/technology)...

1. Uses Crypto API for Windows. - Please use a better cryptographic library that people have trust in like the Mozilla NSS and OpenSSL suite.
2. According to the technology described for Peer Discovery, BTSync sends out SHA1(Secret):IP:Port to solicit response. It is as good as tell the world that your IP address and Port is open for a specific protocol without people needing to probe your network at all. Sending out a SHA-1 hashed Secret is the greatest danger in this PEX protocol. It is as good as handing out an obfuscated secret key to the world and if someone copies it, they could match it against a rainbow hash table and compromise your security. The better way to do a secret key negotiation and authentication protocol is to secure randomly generate a one-time secure random and use your secret to encrypt the one-time random and distribute it via a key exchange protocol.
3. Sync Trackers and Torrent Servers are a good way of caching your communications and key exchanges. It is as good as giving your adversaries a public cache of your activities. If you want serious security, you should leave as little traces as possible. Metadata are obviously one of the best traces as you can create an activity record more easily.

 Now we have seen the theoretical major weaknesses of Bittorrent Sync, let's try to fix it.

1. For the cryptographic APIs, use NSS and OpenSSL. These are highly recognized and open source libraries. For randoms on Unix systems, use the urandom.
2. The PEX protocol requires an overhaul to include a much more Shared Secret Exchange Protocol I shall describe here (SHASEX). For this SHASEX protocol, it shall remain in the public, unlicensed and unpatented forever and I genuinely am unaware of any such patents or inventions/creations when I write this SHASEX protocol version 1 here.

   1.     We shall assume that all clients have the same shared secret key loaded (K).

   
   

   2.     The party that requests communication to all clients generates a random (R) and uses the secret key shared amongst them (K) to encrypt R. Thus, EK(R) and sends it to everyone known.

   
   

   3.     Since everyone has the same shared secret, everyone decrypts the random which is no used as a shared negotiation key so that every client can establish their unique session keys. All clients would randomly generate their own session key independently with the requestor. Let U be the unqiue random each client generates at random for their own session keys. Now all clients would use the R random to encrypt their U random thus. ER(U) and sends it to the requestor.

   
   

   4.     The requestor would consolidate all the client's session key, U, and communicate to them using their own session keys (no sharing of session keys for privacy).

   
   

   5.      By this method, when an attacker from the outside looks at this protocol, all he sees are encrypted values moving around, not plain hashed keys. When the attacker views the session keys, they will have values that are not the same due to the usage of different session keys. Thus, if an attacker were to collect all the encrypted session keys, he would need to break a variety of keys in order to get to the same data and the same data, due to being encrypted with different session keys that are securely generated, would also appear different thus making cryptanalysis even harder.

   
   

   6.     The weakness of this SHASEX protocol to my knowledge and is an unintended consequence of such distributed, decentralized and lightweight design would be to compromise one of the clients hosting the same shared secret keys, intercept all their keys and do a man-in-the-middle.... that if ... the attacker manages to know the secret key by compromising any of the clients. To prevent the stagnation of secret keys, it is best to discard and regenerate shared secrets everytime a session has been ended. The requestor would have to generate a random shared secret and encrypt them with the session keys, distribute the secrets, before closing the connection.

   
   
3. To try to lessen footprints on servers and trackers, try to use less of them.

These are all the comments and recommendations I have now for the improvement of the BTSync protocol.

Lessons for Crypto-Currencies

There is an increasing frequency in the number of break-ins and stealing of crypto-currency wallets from individuals, online crypto-currency exchanges and cryot-currency "banks". Some "dooms-day" advocates whose agenda is to erase crypto-currency from the face of the world or to exploit such situations would hype up these break-ins.

It is not the end for crypto-currencies as the concepts and ideologies that led to the birth and blooming of crypto-currencies are rooted in the dismay and hopes of people who want to see some sort of currency that would allow them to gain more control and trust in the currencies they use.

In this post, I would give some suggestions on how to increase the security of existing and future crypto-currencies.

1. Secure that wallet !!
The weakest security in most protocols are the end-points as most protocols simply add end-point security as some sort of an after thought. Protocols should be designed secure for both data in transit and data at rest.The usual rant for end-point security...
• Use strong and well recognized cryptographic algorithms to encrypt wallet data.
• Use a well audited and well-known cryptographic provider API/software when coding those end-point security codes.
• Do not use passwords as raw input for cryptographic engines or store passwords in raw form.
• Design a time-out that would occur when users present too many wrong passwords during login.
• Try to clear away unused sensitive materials (wallet credentials and keys) from the computer memory as soon as possible.




2. Disposable secondary keys.
Carrying a secondary "credit card" which can be disposed readily is a nice to have feature for crypto-cuurrency. Carrying one's crypto-currency all over the place would mean your wallet is prone to someone grabbing it or you losing it by accident due to carelessness. Allowing a "bank" or some form of centralized authority to govern your crypto-wallet is a bad idea as it makes you "un-anonymous" as your identity would become tied to some known crypto-wallet. Crypto-currencies were designed to be decentralized, so please keep it that way and not allow some form of central management to escrow your crypto-currency assets.

Borrowing the idea of having your main crypto-currency private key (root key) as your root "Certificate Authority", you can independently generate as many independent transaction keys (you do not need to use the main private key as a seed to generate sub-keys of any sorts) and then use your root key to cryptographically sign (sign) your transaction keys and you carry these transaction keys with you to do crypto-currency transactions whenever you want. Any transactions using your transaction keys is as good as using your root key until your root key signs a "revocation announcement" that would disable the transaction keys (in cases where your transaction keys get stolen or you just want to disable them) you specify from performing anymore transactions. The crypto-currency protocol implementing such a method would have to support some form of invalidation and revocation of keys and auditing of keys and transactions (protecting transactions that uses invalid or disabled keys from executing while still retaining anonymity and decentralized structures).

Overall, crypto-currencies are a valid innovation and would still draw huge attention and experience large fluctuations of their values. It is about time the creators and maintainers of existing and future crypto-currency sit down and reconsider what I said above.

How to fool SSL/TLS in your workplace

Read: http://www.h-online.com/security/news/item/Trustwave-issued-a-man-in-the-middle-certificate-1429982.html


SSL/TLS scheme have proven itself to be ineffective at protecting data confidentiality and authenticity of client/servers anymore. It is time something changed.