Friday, July 4, 2014

National Security VS Personal Security

National Security and Personal Security are two differing yet similar security paradigms with different ends and means. The public image of National Security is the Government must protect the privacy, integrity and confidentiality of the National Infrastructure and also those of the people it governs. There are many cases of the Government breaching such trust and faith the people have invested into them to protect the people's liberty, rights, privacy, security and integrity (LRPSI). Governments have also taken measures to intrude into the lives of the people it is suppose to protect by introducing or using multiple robust laws, measures and techniques to ensure that to achieve "National Security", the LRPSI of the people it is suppose to protect are frequently broken and intruded upon. In some uncommon cases, such intrusion of the people'sLRPSI may lead to cases of miscarriage of justice.

Below is a table that will quickly summarize my view of National Security and Personal Security in the current context.

Some may argue that National Security and Personal Security can go hand in hand but the current scenarios and political landscapes around the world implies that many Governments are willing to sacrifice their own people in the supposed name of "National Security" which makes the Governments' infrastructure strong but in turn weakens the LRPSI of the people as a whole.


National SecurityPersonal Security
Robust security on a governmental and national infrastructural levelRobust security on a personal level
Restriction of civilian security technology below it's own surveillance powers.Personal security should be as strong as available
Subversion of LPSRI to achieve population controlExercises full LPSRI rights via means of secure technologies
Maximum surveillance and subversionMaximum counter-surveillance, anonymity and security
Top-down control of infrastructures and technoloogiesIndividual personal control
Derive benefits via surveillanceDerive benefits via LPSRI

The current trend of National Security VS. Personal Security seems to be leaning more towards anti-LPSRI goals. Governments touting that National Security and Patriotism is not a Zero-Sum game is mostly false due to the fact that building a National Security infrastructure requires huge surveillance capabilities and the suppression of secure technologies that prevent surveillance capabilities from working due to the nature of surveillance which requires the possession of large amounts of personal information to be able to effectively execute population profiling, tracking and interdiction of possible threats / "threats".

Thursday, July 3, 2014

Passwords in Database

It is inevitable that user passwords would be stored into databases for a good amount of applications in the wild. Most of the stored passwords in databases are weakly protected or left alone in plaintext. Application developers would usually blame security as a difficult task (which is very true) and those developers without adequate knowledge of computer security and cryptography would usually do a bad job at securing sensitive data like user passwords. Database makers may also be partially faulted for not adding features that ensure strong data security which database makers would usually point out that data security is not the main aim of their databases they distribute and would push the blame back to the application developers for not making their application data secure.

Indeed security is difficult but it can be easily solved if everyone (from the application developers to the cryptographers and database makers) were to sit down and put their minds together to make security easy for plain users. Below are some suggestions that I have to make data security easy for passwords stored in databases.


  1. Make crypto-libraries simple for developers and with as little frustration connected to dependencies as possible. Developers should simply need to call an easy to use API that is straightforward. Developers should not need to know a lot on cryptography to use it. An example is developers should call "passwordEncrypt('bcrypt'.'this15MyPassw0rd');" and that's all they need. If they need to tweak settings, they can call "passwordEncryptTweak('rounds',10000000);" or something similar. The API documentations should be simple and concise for the developers to use.
  2. Database developers may want to facilitate password security by introducing a Password type object that returns a hexadecimal string of the hashed/encrypted password. All Password type objects would be hashed/eencrypted according to the algorithm set inside the database properties and should support common password hashing methods like BCRYPT, SCRYPT and PBKDF2. Furthermore, a 'authenticate()' command can be issued against a Password object that takes in a string to return a boolean output whether the password object has been authenticated correctly. This will facilitate password security stored in databases.
  3. Store user accounts and passwords in a highly protected computer system with limited user access. One way is to setup a user database server that have a strict set of protected API that the application have to call. During authentication, the application server would pass user login request to the user account server that would valid the login before returning the response to the application server. Only the application server should have access to the user account server.
  4. Make use of login services from login providers (Google, Facebook, Twitter ...) instead of storing user passwords and handling logins on your own.

Wednesday, June 11, 2014

Verified Truecrypt Copies

The OCAP Project have announced the release of verified copies of Truecrypt 7.1a, below is the Github repository containing verified copies of the version 7.1a binaries and source codes.


Wednesday, May 28, 2014

Truecrypt Compromisation

Recently, Truecrypt webpage (www.truecrypt.org) was shown to be compromised. It comes along with a version 7.2 of Truecrypt that looks suspicious. Do NOT download any Truecrypt software from that website from the website from now and DO NOT switch to Bitlocker before a confirmation of what is going on has been thoroughly investigated.

If you are using version 7.1a and older of Truecrypt, you are most likely to be fine for now.

I will see what I can do to provide people following my blog or those who are interested with a replacement.

If you have further doubts of Truecrypt, please migrate to LUKS (https://code.google.com/p/cryptsetup).

Remember, DO NOT TRANSFER FILES UNENCRYPTED ! Even a Truecrypt container (version 7.1a and older) used to move secrets is much better than nothing.


Friday, May 23, 2014

Beginner's Truecrypt File Encryption Guide

Disclaimer:
I hereby excuse myself of all responsibilities for the posting of this guide on the use of Truecrypt. Anyone following this guide on the use of Truecrypt are liable for the use at their own risk. By following any steps of this guide, you (the reader) have willingly bound yourself to this Disclaimer and have excused me of any responsibilities on this guide's procedures and recommendation on the use of Truecrypt or any other digital components being used together with the use of Truecrypt and you shall be solely responsible for the use of Truecrypt and any other digital components being used together with the use of Truecrypt.


Summary:
This guide on the basic usage of Truecrypt teaches beginners the basic procedures and steps in creating and utilizing their very own Truecrypt secure volume to store sensitive secrets securely away from prying eyes.


Basic Information:
Truecrypt does not encrypt files individually but rather creates a secure volume to store files within that secure volume. Think of a secure volume as a secure folder or a secure virtual device (it is considered a virtual hard disk volume by the Operating System) where you store your collection of data files in a secure collection called a secure volume.


Operational Security:
When you are using Truecrypt, please observe these following guides for your own personal safety due to the fact that if you misuse Truecrypt without proper Operational Security (OpSec) in mind, you are likely going to have someone come along and compromise your secure volumes.
  1. Check for traps or tappings connecting between your keyboard and mouse wires or Bluetooth connectors to the CPU if you are using a Desktop or a Server. If your connecting wires or USB Bluetooth dongle between the CPU and the connecting wires of Bluetooth dongles have suspicious looking adapters that have not been installed by you, take precaution and discontinue and investigate until you feel safe.
  2. Secure volume file names should not have meaning to it. One bad example of a secure volume file name is 'mysecrets.tc'. You are as good as broadcasting to anyone who intrudes or shares the computer that the file is something of a sensitive nature.
  3. Secrecy of secure volume master passwords are paramount. You must find a way to secure the password without leaking or sharing them. Sharing of passwords are strictly not allowed regardless of scenarios. We will cover on sharing Truecrypt volume on a later chapter but for now, do not share anything. Writing down the password, sealing it in an envelope and quickly locking it up in a safe is one of the most common methods of storing your password away. Never carry the written down passwords anywhere and carelessly leave them lying around as these secret passwords are the key to your sensitive data. You are better off storing your master secret password in a Password Manager (Passwordsafe) or simply attempt to remember it by choosing a passphrase that you can easily recall.
  4. Do not unnecessarily reveal the existence of your secure volumes.
  5. Dismount your volumes when you have done all your work and quit the Truecrypt program if possible.
  6. If you have any sensitive files you want to create, please try to create them within the secure volume as it provides more security than to create a file outside the secure volume on your Desktop and later copying it into the secure volume. Computer forensics analysis maybe able to recover files created on your Desktop if you create the files on the Desktop before moving it into the secure volume.
  7. It is best if you limit the sizes of your secure volumes (recommended between 1 to 5 MB per volume) as huge file sizes attracts attention. Having multiple small volumes work better but can be confusing to organize them so you need some form of unrecognizable naming convention that seems random and only you know the meaning of the secure volume names. If you want to have one big central secure volume, you must take all your attention required to secure and keep it protected (not saying that smaller volumes means you can be careless).

Steps:
  1. Download Truecrypt (http://www.truecrypt.org/downloads).



  2. Run the installer and click 'Yes' to all.
  3. Click on the Truecrypt program.

  4. Create a new volume to store your sensitive files by clicking on the 'Create Volume' button. A 'Truecrypt Volume Creation Wizard' window should appear.

  5. Select the default 'Create an encrypted file container' and click 'Next >' to continue.

  6. You will be asked to choose your volume type and you should select 'Standard Truecrypt Volume' for now.

  7. Type or select the file you want to use as your Truecrypt volume. I would suggest you to create the secure volume file in the 'C:\' drive location first and then copy it to wherever you want. Make sure you copy and SHIFT+DELETE the file in the 'C:\' drive once you have copied it out. The filename should be meaningless to anyone except probably you. If you want a truely secure file name that no one knows the meaning including yourself, you can use a random generator (http://www.random.org/strings/) to generate a random file name.


  8. Click 'Next >' and you would be shown an 'Encryption Options' to select your encryption algorithm. Select 'Serpent-Twofish-AES' for your 'Encryption Algorithm' and select 'RIPEMD-160' for your 'Hash Algorithm'. Click 'Next >' to continue.


  9. Select on a volume size you want for your volume. Your storage capacity would be slightly smaller than the volume size you have selected because you need to store other file information inside the encrypted volume. Click 'Next >' to continue.

  10. Select a volume password for encrypting your volume. Please choose your passwords wisely and make sure you take utmost care of your passwords. Click 'Next >' to continue. If you are warned that you are using a short password, in the screen below, you can click 'Yes' to continue to use the password you selected or click 'No' to select another password that is much longer. Do NOT panic when you are warned of the short password as shown in the picture below. You are NOT FORCED to use a long password. You may use a short password as long as you choose it carefully ! Stick to common sense like not using a commonly known password and mix the letters and numbers in your passwords and do not re-use old passwords. The stronger your password (more letters, numbers, special characters and longer passwords) the harder an adversary needs to work to attempt to crack your passwords.




  11. You would be asked to choose a 'Volume Format'. We shall use the default volume format (FAT format) so do not touch the format unless you know what you are doing. Start moving your mouse randomly across the window to generate some random secrets as part of the encryption mechanism. You will see the 'Random Pool' changing all the time as you move your mouse randomly. Once you are satisfied, click 'Next >'.

  12.  You will be notified that your volume has been created. Click 'Yes' and 'Exit' to finish the creation.



  13. Once you are done, a file would be created as your Truecrypt volume to store your sensitive files. If you use a text editor to open the file, it should look like a bunch of random unreadable binary. You should avoid opening the file by the means of a text editor to prevent accidental corruption of the binary. You may want to backup this file as often as possible. Below is a created file shown on the Desktop and also a small snapshot of the random binaries when carefully opened using a text editor.



  14. To open the Truecrypt volume for use (it is called mounting a volume), Click on a Drive to allocate a Drive (E:\, F:\ ...) to mount the volume onto. Click on 'Select File' and select your Truecrypt volume file to mount for use. Click 'Mount' to mount the selected file on to the selected Drive. In this picture below I have selected 'H:' drive for use. You may select any free drive to use. Please ensure that the 'Never save history' option is ticked to prevent saving a history of visited volumes to prevent any knowledge of your activities leaked.


  15. You will be prompted to enter your password and when you have entered your password click on 'OK' to continue.


  16. Once you have successfully mounted the volume, you will see your volume mounted next to your 'Drive' with the volume file size, encryption algorithm used and other volume information.


  17. Go to the mounted volume (if you select 'H:', that means you need to navigate to 'H:' drive on your computer using your file manager/browser). You may start creating and adding files to be secured within the volume. If you are going to be away from computer, please close all the text editors or document editors of the sensitive files you are currently editing or using  and click on the 'Dismount All' to dismount all volumes. It is insecure to leave your volume mounted while you are away from your computer even for a short moment as anyone can walk to your seat and take over your computer and do something to your secure volume (making it insecure because you left it mounted and unattended). Dismounting the volume means that the files and volumes would return back to an encrypted state and requires password login again to decrypt the volume and access the sensitive files. When you dismount it should not exist on your list of Drives and volumes anymore as shown in the screenshot below.
    Some files created










    Dismounted all volumes

Monday, May 19, 2014

Techno-Politics and Journalist Security in Singapore

Read:
Three generations of Singapore's top officials have used the tactic of forcefully pushing bloggers and vocal Singapore netizens against the wall via legal threat. Instead of using peaceful debates to proof to the netizens that their accusations are baseless, these top officials of Singapore have chosen to use unrestricted force upon sight to bring down anyone who are against them.

In my opinion, the accused officials should step up and take challenges instead of using unusually forceful means to subdue the views of those they find unpleasing and learn some humility and appreciation for the comments of others regardless if they are nice or not. To prove that the accuser is wrong, they can make their processes very transparent and invite outside parties to audit their systems and processes. If they can take challenges and show humility, not simply trying to get rid of others who they don't like, they will gain respect and respect is key to their reputation. The inverse which is simply being full of themselves and attacking by unusually forceful means would not gain much reputation. They simply look very ugly.

Put it simply, in Singapore, you need to publish articles that will not disagree with the people in power. Disagreement in itself is seen as equivalent to treason here. There is very little security provided to journalists and bloggers who want to post materials that may not be suited to the views of those in power as they may not take lightly any attempts at challenging their power and reputation. Below are some security mechanisms journalists and bloggers can consider below on taking a DEFENSIVE stance to protect themselves and their assets:
  • Data hosted in foreign jurisdictions. This means that if someone wants to challenge you to take your data down, you and the aggressor need to obey the legal proceedings of the jurisdiction where the data is hosted. The very nature of jurisdiction if used properly can make it harder for an aggressor to push their way through. You need to pick your data hosting countries properly. Switzerland and Germany is a good place to start. Certain Scandinavian countries would also provide good data protection laws.
  • Rally more debate if threatened. Get more attention and more support whenever can while maintaining OPSEC (Operational Security) as posted in this article.
  • Data duplication and high-availability options. Create mirror backups of contents that are sensitive. Copy and distribute copies of works as often as you can. Use 7zip, Gzip and other compression formats to compress large data archives and upload them on online upload storage (DO NOT use Dropbox as they are pro-Institutions) and spread the links. Run torrents if you need to. Using this method, if one person (most likely you) go down and brought down, there will be many other like-minded ones who will continue to bring the debate back online.
  • Proper use of Cryptography to protect their personal data and the protection of secret keys and passwords/passphrases despite coercion. 7zip archive format includes AES encryption to encrypt your own files with passwords. Have a good sense of password policy (mix characters with 12 characters and do not re-use passwords at the very least). Use of the Truecrypt file encryption utility would save you and make it absolutely difficult for agressors to decrypt your file as long as your master passwords and encryption keys are safe. Do not reveal passwords/passphrases under coercion.
  • Use of PGP/GPG email encryption will enable private communications. Make sure to install Truecrypt and create a secure file volume and generate your PGP/GPG ermail encryption keys inside the Treucrypt secure volume so that your secret email keys would not hang loosely in your untrusted PC !
  • DO NOT USE THESE ALGORITHMS FOR ENCRYPTION: RC4, DES, 3DES/TripleDes.
  • DO NOT SHARE ACCOUNTS, PASSWORDS AND SECRET KEYS !!!
  • Do not post something online when you don't want it to be known. Whatever data posted online and collected by aggressors would be used against you to remove your credibility, so for goodness sake, keep your online activities clean from now on and have a good security habit. Try to use HTTPS whenever you can (you can install HTTPS Everywhere browser plugin (https://www.eff.org/https-everywhere) and it will always steer you to a HTTPS connection whenever possible).
  • If you are in an untrusted environment, use a TAILS Linux Live CD (https://tails.boum.org/index.en.html).
  • Keep a separation between sensitive personal information and public information for goodness sake. If you need an air-gap computer (a computer that has no network by switching off it's network capability or physically removing it's network card and using USB stick to transfer sensitive information) to process sensitive personal information.
  • If you are more technically savy, try to setup your own Rubberhose Filesystem (https://web.archive.org/web/20110726185300/http://iq.org/~proff/rubberhose.org/).
  • Lastly for this article, all these troublesome security is in place to KEEP YOU SAFE.



Thursday, May 1, 2014

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 ?

Thursday, April 17, 2014

Kill switch your smartphone

Read:
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.

Friday, April 11, 2014

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.

Tuesday, April 8, 2014

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.



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.

Wednesday, April 2, 2014

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.

Wednesday, March 5, 2014

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 !!
  2. 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.


  3. Disposable secondary keys.
  4. 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.