Internet censorship and loss of privacy


An excellent essay by Bruce Schneider on government organized initiatives worldwide to reduce internet privacy and for censorship. There is also evidence that criminals can (mis)use such infrastructure for their own purpose. Please click here to read.

Every year brings more Internet censorship and control — not just in
countries like China and Iran, but in the United States, the United
Kingdom, Canada and other free countries.

The control movement is egged on by both law enforcement, trying to
catch terrorists, child pornographers and other criminals, and by media
companies, trying to stop file sharers.

It’s bad civic hygiene to build technologies that could someday be used to facilitate a police state. No matter what the eavesdroppers and censors say, these systems put us all at greater risk. Communications systems that have no inherent eavesdropping capabilities are more secure than systems with those capabilities built in.


Automate encryption with GPG


This blogpost requires some familiarity with GPG.

Today I want to share the scripts for running GPG in the batch (unattended) mode. You can have a password on the keys if you want, but since this is the automated mode, you may want to use keys without a password. Irrespective of whether or not you use a password – use a separate set of keys that you will not use for anything that not batch processed. The scripts are primarily for Linux. If you need them for Windows, please read this and post any problems you face in comments section, and I will help.

The script for encryption is here:

#! /bin/sh
gpg --batch -r <reciepient> --output $2 --passphrase-fd 3 --sign --encrypt $1 3</apps/gpg/passph

The first line shows the location of the shell – please change it according to where the shell is on your system. The second line has the location of the folder where the keys are located – the pubring.gpg and secring.gpg. In the last line, replace <reciepient> with the name on the reciepient key. The /apps/gpg/passph points to the location of the file containing the passphrase. The script will both sign and encrypt the file – change this to suit your needs. The script expects the name of the input file and the name of the output files as parameters in that order.

The script for decryption is here:

#! /bin/sh
gpg --batch --passphrase-fd 3 --status-fd 1 --decrypt $1 3</apps/gpg/passph | grep '\[GNUPG:\] GOODSIG'
if [ $? -eq 0 ]; then
  gpg --batch --passphrase-fd 3 --output $2 --decrypt $1 3</apps/gpg/passph

The first three lines are similar. Line 4 just checks if the file has a valid signature. If you want to skip this step remove lines 4, 5 and 7. No effort is made to see who signed the file. In my scenario, I could control the people who could sign by having only those public keys in the repository, and the repository could only be written to by ‘root’.

Please post comments in case of questions, concerns.



Shows that FTP+GPG combination cannot be used in place of SFTP – SFTP is still more secure. Also includes a howto document on setting up passwordless SFTP based automated file transfers.

Recently, we needed to setup secure file transfer with a third party that did not support SFTP. Hence we decided to use FTP+GPG – which includes transfer of GPG encrypted files with FTP. For more details on GPG, visit the homepage It can also operate in ‘portable’ mode – from a USB key.

We did not realise that this combination is still significantly less secure that SFTP based transfer. The threats it does not cater to, which SFTP can combat are:

  • Someone can come to know about the username, password used in the connection since this is still being transferred un-encrypted
  • Using this, someone can load their own files into the server which can be designed to either infect the system, or upload malicious information

Even if GPG signatures are used (as we did after coming to know about these shortcomings), there is still the risk of someone replaying the same files that we received. Even this can cause problems in certain situations. Hence, we had to resort to fixing the source IP to combat the problems. Due to using signatures and IP fixing, it all turned out to be more cumbersome, and still less secure.

The best way currently to establish automated file transfers is to do a password-less SFTP. It does not require any password transfer over the network at all, keeps everything encrypted, and: a disgruntled employee who happens to remember a password (in case of password based SFTP) cannot disrupt your services.

This document contains instructions on how to set this up: Password SFTP – How to setup. There is also an online version of the same document. If you have any questions, please post as comments.