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 Security	Personal Security
Robust security on a governmental and national infrastructural level	Robust 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 control	Exercises full LPSRI rights via means of secure technologies
Maximum surveillance and subversion	Maximum counter-surveillance, anonymity and security
Top-down control of infrastructures and technoloogies	Individual personal control
Derive benefits via surveillance	Derive 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".

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.

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.

•  OCAP Announcement: https://twitter.com/OpenCryptoAudit/status/476192449614708736

• Truecrypt 7.1a: https://github.com/AuditProject/truecrypt-verified-mirror

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.

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

Techno-Politics and Journalist Security in Singapore

Read:

• https://sg.news.yahoo.com/singapore-pm-demands-apology-blogger-084428281.html

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.

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 ?