Encryption

REVIEW: “Rainbows End”, Vernor Vinge

BKRNBSND.RVW   20130525

“Rainbows End”, Vernor Vinge, 2006, 0-312-85684-9, U$25.95/C$34.95
%A   Vernor Vinge
%C   175 Fifth Avenue, New York, NY  10010
%D   2006
%G   0-312-85684-9
%I   Tor Books/Tom Doherty Assoc.
%O   U$25.95/C$34.95 pnh@tor.com www.tor.com
%O  http://www.amazon.com/exec/obidos/ASIN/0312856849/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0312856849/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0312856849/robsladesin03-20
%O   Audience i+ Tech 2 Writing 3 (see revfaq.htm for explanation)
%P   364 p.
%T   “Rainbows End”

It is always a pleasure to read something from Vinge.  His characters are interesting, his plots sufficiently convoluted, and his writing clear and flowing.  In addition, for the geek, his understanding of the technology is realistic and fundamental, which makes a change from so many who merely parrot jargon they do not comprehend.

Of course, this is future technology we are talking about, so none of it is (currently) real.  But it could be, without the wild flights of illogic that so abound in fiction.

In this book, we have a future with interconnectedness around the globe.  Of course, this means that there are dangers, in regard to identity and authentication.  The new technology protects against these dangers with a Secure Hardware Environment.  (Or SHE, and, since the DHS mandates that everyone must use it, does that make it SHE-who-must-be-obeyed?)

Encryption is, of course, vital to the operations, and so is used a lot, often in multiple layers.  It is probably a measure of the enjoyability of Vinge’s work that I really didn’t take note of the fact that two of the characters were named Alice and Bob.  Not, that is, until late in the volume, when the author also briefly introduces a character named Eve Mallory.

copyright, Robert M. Slade   2013   BKRNBSND.RVW   20130525

Hardening guide for NGINX 1.5.8 on RedHat 6.4 (64bit edition)

This document explains the process of installation, configuration and hardening of NGINX server from source files, based on CentOS 6.4 default installation (IPTables and SELinux enabled by default), including support for TLS v1.2 and protection from BEAST attack and CRIME attack
 
Some of the features explained in this document are supported by only some of the Internet browsers:

  • X-Frame-Options – Minimum browser support: IE 8.0, Firefox 3.6.9, Chrome 4.1.249, Opera 10.50, Safari 4.0
  • TLS 1.2 – Minimum browser support: IE 8.0 on Windows 7/8 (Need to be enabled by default), Firefox 24.0 (Need to be enabled by default), Chrome 30, Opera 17, Safari 5.0
    1. Installation Phase

    2. Login to the server using Root account
    3. Install pre-requirement packages:
      yum install policycoreutils-python-* -y
      yum install setools-libs-* -y
      yum install libcgroup-* -y
      yum install audit-libs-python-* -y
      yum install libsemanage-python-* -y
      yum install setools-libs-python-* -y
      yum install gcc* -y
    4. Create a new account:
      groupadd nginx

      useradd -g nginx -d /dev/null -s /sbin/nologin nginx

    5. Upgrade the Openssl build:
      rpm -ivh --nosignature http://rpm.axivo.com/redhat/axivo-release-6-1.noarch.rpm

      yum --enablerepo=axivo update openssl -y

    6. Download Openssl source files:
      cd /opt

      wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz

    7. Extract Openssl source files:
      tar zxvf /opt/openssl-1.0.1e.tar.gz -C /opt
    8. Remove Openssl source file:
      rm -rf /opt/openssl-1.0.1e.tar.gz
    9. Download PCRE source file into /tmp, from:
      http://sourceforge.net/projects/pcre/files/pcre/
    10. Compile PCRE from source file:
      tar zxvf /tmp/pcre-8.34.tar.gz -C /tmp

      mv /tmp/pcre-8.34 /usr/local/pcre

      cd /usr/local/pcre

      ./configure --prefix=/usr/local/pcre

      make

      make install

    11. Remove PCRE package:
      rm -rf /tmp/pcre-8.34.tar.gz
    12. Download Nginx 1.5.8:
      cd /tmp

      wget http://nginx.org/download/nginx-1.5.8.tar.gz

    13. Extract the nginx-1.5.8.tar.gz file:
      tar -zxvf /tmp/nginx-1.5.8.tar.gz -C /tmp
    14. Move to the Nginx source folder:
      cd /tmp/nginx-1.5.8
    15. Edit using VI, the file
      /tmp/nginx-1.5.8/src/http/ngx_http_header_filter_module.c and replace the following section, from:
      static char ngx_http_server_string[] = "Server: nginx" CRLF;

      static char ngx_http_server_full_string[] = "Server: " NGINX_VER CRLF;
      To:
      static char ngx_http_server_string[] = "Server: Secure Web Server" CRLF;
      static char ngx_http_server_full_string[] = "Server: Secure Web Server" NGINX_VER CRLF;

    16. Run the commands bellow to compile the Nginx environment:
      ./configure --with-openssl=/opt/openssl-1.0.1e --with-http_ssl_module --without-http_autoindex_module --without-http_ssi_module --with-pcre=/usr/local/pcre
      Note: The command above should be written as one line.
      make

      make install

    17. Remove the Nginx source files:
      cd /

      rm -rf /tmp/nginx-1.5.8

      rm -f /tmp/nginx-1.5.8.tar.gz

    18. Remove Default Content
      rm -rf /usr/local/nginx/html
    19. Updating Ownership and Permissions on Nginx folders:
      chown -R root:root /usr/local/nginx

      chmod 750 /usr/local/nginx/sbin/nginx

      chmod -R 640 /usr/local/nginx/conf

      chmod -R 770 /usr/local/nginx/logs

    20. Create folder for the web content:
      mkdir -p /www
    21. Updating Ownership and Permissions on the web content folder:
      chown -R root /www

      chmod -R 775 /www

    22. Edit using VI the file /usr/local/nginx/conf/nginx.conf and change the following settings:
      From:
      #user nobody;
      To:
      user nginx nginx;

      From:
      #error_log logs/error.log notice;
      To:
      error_log logs/error.log notice;

      From:
      server_name localhost;
      To:
      server_name Server_FQDN;
      Note: Replace Server_FQDN with the actual server DNS name.

      From:
      root html;
      To:
      root /www;

    23. Add the following sections to the end of the /usr/local/nginx/conf/nginx.conf file (before the last “}” character):
      ## turn off nginx version number ##
      server_tokens off;
      ## Size Limits & Buffer Overflows ##
      client_body_buffer_size 1K;
      client_header_buffer_size 1k;
      client_max_body_size 1k;
      large_client_header_buffers 2 2k;
      ## Timeouts ##
      client_body_timeout 10;
      client_header_timeout 10;
      send_timeout 10;
    24. Create using VI, the file /etc/init.d/nginx with the following content:
      #!/bin/sh
      #
      # nginx - this script starts and stops the nginx daemon
      #
      # chkconfig: - 85 15
      # description: Nginx is an HTTP(S) server, HTTP(S) reverse \
      # proxy and IMAP/POP3 proxy server
      # processname: nginx
      # config: /usr/local/nginx/conf/nginx.conf
      # config: /etc/sysconfig/nginx
      # pidfile: /var/run/nginx.pid

      # Source function library.
      . /etc/rc.d/init.d/functions

      # Source networking configuration.
      . /etc/sysconfig/network

      # Check that networking is up.
      [ "$NETWORKING" = "no" ] && exit 0

      nginx="/usr/local/nginx/sbin/nginx"
      prog=$(basename $nginx)

      NGINX_CONF_FILE="/usr/local/nginx/conf/nginx.conf"

      [ -f /etc/sysconfig/nginx ] && . /etc/sysconfig/nginx

      lockfile=/var/lock/subsys/nginx

      start() {
      [ -x $nginx ] || exit 5
      [ -f $NGINX_CONF_FILE ] || exit 6
      echo -n $"Starting $prog: "
      daemon $nginx -c $NGINX_CONF_FILE
      retval=$?
      echo
      [ $retval -eq 0 ] && touch $lockfile
      return $retval
      }

      stop() {
      echo -n $"Stopping $prog: "
      killproc $prog -QUIT
      retval=$?
      echo
      [ $retval -eq 0 ] && rm -f $lockfile
      return $retval
      }

      restart() {
      configtest || return $?
      stop
      sleep 1
      start
      }

      reload() {
      configtest || return $?
      echo -n $"Reloading $prog: "
      killproc $nginx -HUP
      RETVAL=$?
      echo
      }

      force_reload() {
      restart
      }

      configtest() {
      $nginx -t -c $NGINX_CONF_FILE
      }

      rh_status() {
      status $prog
      }

      rh_status_q() {
      rh_status >/dev/null 2>&1
      }

      case "$1" in
      start)
      rh_status_q && exit 0
      $1
      ;;
      stop)
      rh_status_q || exit 0
      $1
      ;;
      restart|configtest)
      $1
      ;;
      reload)
      rh_status_q || exit 7
      $1
      ;;
      force-reload)
      force_reload
      ;;
      status)
      rh_status
      ;;
      condrestart|try-restart)
      rh_status_q || exit 0
      ;;
      *)
      echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload|configtest}"
      exit 2
      esac

    25. Change the permissions of the file /etc/init.d/nginx
      chmod +x /etc/init.d/nginx
    26. To start Nginx service at server start-up, run the command:
      chkconfig nginx on
    27. To manually start the Nginx service, use the command:
      /etc/init.d/nginx start
    28. Configure IPTables:
      service iptables stop

      iptables -P INPUT DROP

      iptables -A INPUT -i lo -j ACCEPT

      iptables -A OUTPUT -o lo -j ACCEPT

      iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    29. Allow SSH access from Internal segment (i.e. 10.0.0.0/8)
      iptables -A INPUT -m state --state NEW -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT
      Note: Replace 10.0.0.0/8 with the internal segment and subnet mask.
    30. Allow HTTP access from the Internet on the public interface (i.e. eth0)
      iptables -A INPUT -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
      Note: Replace eth0 with the public interface name.
    31. Save the IPTables settings:
      service iptables save
      SSL Configuration Phase

    1. Login to the server using Root account.
    2. Create folder for the SSL certificate files:
      mkdir -p /usr/local/nginx/ssl

      chmod 600 /usr/local/nginx/ssl

    3. Run the command bellow to generate a key pair:
      /usr/bin/openssl genrsa -aes256 -out /usr/local/nginx/ssl/server-sec.key 2048
      Note: Specify a complex pass phrase for the private key (and document it)
    4. Run the command bellow to generate the CSR:
      /usr/bin/openssl req -new -newkey rsa:2048 -nodes -sha256 -days 1095 -key /usr/local/nginx/ssl/server-sec.key -out /tmp/server.csr
      Note: The command above should be written as one line.
    5. Send the file /tmp/server.csr to a Certificate Authority server.
    6. As soon as you receive the signed public key from the CA server via email, copy all lines starting with “Begin” and ending with “End” (include those two lines), into notepad, and save the file as “server.crt”
    7. Copy the file “server.crt” using SCP into /usr/local/nginx/ssl
    8. Follow the link on the email from the CA server, to create the Root CA chain, and save it as “ca-bundle.crt” (Note: The file must be PEM (base64) encoded).
    9. Copy the file “ca-bundle.crt” using SCP into /usr/local/nginx/ssl
    10. Combine the content of both the public key (server.crt) and the Root CA chain (ca-bundle.crt) into one file:
      cat /usr/local/nginx/ssl/ca-bundle.crt /usr/local/nginx/ssl/server.crt > /usr/local/nginx/ssl/server.pem
      Note: The command above should be written as one line.
    11. Remove the key store passphrase:
      /usr/bin/openssl rsa -in /usr/local/nginx/ssl/server-sec.key -out /usr/local/nginx/ssl/server.key
      Note: The command above should be written as one line.
    12. Remove the original “server.crt”, “server.csr” and “ca-bundle.crt” files:
      rm -f /tmp/server.csr

      rm -f /usr/local/nginx/ssl/server.crt

      rm -f /usr/local/nginx/ssl/ca-bundle.crt

    13. Edit using VI the file /usr/local/nginx/conf/nginx.conf and replace the section bellow from:
      # HTTPS server
      #
      #server {
      # listen 443 ssl;
      # server_name localhost;
      # ssl_certificate cert.pem;
      # ssl_certificate_key cert.key;
      # ssl_session_cache shared:SSL:1m;
      # ssl_session_timeout 5m;
      # ssl_ciphers HIGH:!aNULL:!MD5;
      # ssl_prefer_server_ciphers on;
      # location / {
      # root html;
      # index index.html index.htm;
      # }
      #}

      To:
      # HTTPS server
      #
      server {
      listen 443;
      server_name Server_FQDN;
      ssl on;
      ssl_certificate /usr/local/nginx/ssl/server.pem;
      ssl_certificate_key /usr/local/nginx/ssl/server.key;
      ssl_session_timeout 5m;
      ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
      ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS:!aNULL:!EDH:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;
      ssl_prefer_server_ciphers on;
      # HTTP Strict Transport Security #
      add_header Strict-Transport-Security max-age=63072000;
      # X-Frame-Options header #
      add_header X-Frame-Options SAMEORIGIN;
      location / {
      root /www;
      index index.html index.htm;
      }
      }

      Note: Replace Server_FQDN with the actual server DNS name.
    14. Configure IPTables – Allow HTTPS access from the Internet on the public interface (i.e. eth0)
      iptables -A INPUT -m state --state NEW -p tcp --dport 443 -i eth0 -j ACCEPT
      Note: Replace eth0 with the public interface name
    15. Remove HTTP access from the Internet on the public interface (i.e. eth0)
      iptables -D INPUT -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
      Note: Replace eth0 with the public interface name
    16. Save the IPTables settings:
      service iptables save
    17. Restart the nginx:
      service nginx restart

    The original article can be found on:
    http://security-24-7.com/hardening-guide-for-nginx-1-5-8-on-redhat-6-4-64bit-edition/

    What TV understands about crypto

    One of only two shows that we actually watch on television is “Murdoch Mysteries.”  Set in Toronto, circa 1900, it shows Detective Murdoch “inventing” much of modern forensics using the technology of the time.  Some of it might actually work  :-)

    The latest episode, “Invention Convention” (season 5 episode 9) had someone promoting “i-mail” (instant mail). which Gloria thought was Telex, and I figured was more akin to fax.  (For those in Canada, CityTV runs “Murdoch” a number of times during the week, but won’t say which ones are the current season, and which are older.  I’m pretty sure this episode will be relayed at 8 pm on Saturday.  For those outside Canada, I’m not sure whether you can watch the episode on the Website.)  Part of the plot turned on someone sending encrypted messages.

    The code used by the group is a form of Ceasar cipher, aided by an Alberti disk.  In reality, by 1700 this probably would have been considered old hat: Casanova writes of breaking what must have been at least a shuffled alphabet cipher.  (In the episode an “analytical engine” is used to try and brute force the Ceasar cipher.)  Autocode and other forms were well established by 1900.  (De Vigenere created one form of autocode, rather than the cipher which bears his name, which he considered weak.)

    In the end, the code turns out to be based on a keyboard layout, which probably was not completely standard by that time.  Which would, in any case, have been a simple substitution cipher, and easily breakable by frequency analysis (one case of which was said to have failed in the plot).

    Passwording: checklists versus heuristics

    The trouble with lists of ‘Top Umpteen’ most-used passwords like Mark Burnett’s is that they don’t really teach the everyday user anything. (Yes, I’m another of those sad people like Rob Slade who believe that education and reducing Security unawareness is actually worth doing.)

    Since I’ve quoted Burnett’s top 500 and one or two other sources from time to time in blogs here and there, I’ve noticed that those articles tend to pick up a fair amount of media attention, and after the Yahoo! debacle I noticed several journalists producing lists of their own. But they’re missing the point, at least in part.

    Not using (say) the top 25 over-used passwords will reduce the risk for accounts that are administered with a ‘three strikes and you’re blocked’ approach to blocking password guessing, but where authentication is less strict, 25 may not be enough. Heck, 10,000 may not be enough. At any rate, if an end user is expected to check that they aren’t using a common password, 10,000 is a pretty big checklist, and still doesn’t provide real protection against a determined dictionary attack. It’s the difference between static signature detection and heuristics: it might be useful to know that ‘password’ is a particularly bad choice because everyone uses it, but which of these approaches is more helpful?

    (1)
    Don’t use ‘a’
    Don’t use ‘aa’
    Don’t use ‘aaa’

    Don’t use ‘aaaaaaaaaaaaaaaaaaaaaaa’
    Don’t use ‘b’
    Don’t use ‘bb’

    (2) Don’t use any password consisting of a single character repeated N times

    See A Torrent of Abuse for a flippant attempt at approach (2) implemented through parody.
    But then, any password is only as good as the service to which it gives access: it doesn’t matter if the provider is incapable of providing competent security: Lessons in website security anti-patterns by Tesco. And I have some sympathy with the view that if you can find a decent password manager it saves you a lot of thinking and reduces the temptation to re-use passwords and risk a cascade of breaches when one of your providers slips up.

    David Harley

    World’s first “Decode the Race car” Challenge!!

    So I haven’t written for a while, and that’s mainly because setting up your own security consultancy takes a lot more time that I would have imagined, but hey, it’s been a fun ride so far.

    So while everyone else is off writing about Sony, I figured that I’d lighten the mood here with something that I think is such a great idea. The guys at Secure Racing have a challenge coming up, which sounds like it’s going to be great fun, and it’s such a novel idea as well.

    So taken directly from the Secure Racing website, here is all the information about the challenge coming up on the 19th June at Brands Hatch.

    “Secure Racing, the Information Security industry’s motorsport team, has laid down a challenge to anyone with a flair for code-breaking or a passion for cryptography.

    At the team’s first race on 19th June at the Brands Hatch circuit in Kent, the Secure Racing Aston Martin will feature a hidden coded message somewhere within its livery and decals. The question is – can you find it and decipher it?
    This is the first time a motorsport team anywhere in the world has offered a competition like this on their car. Developed by the Threats and Vulnerabilities Team at PWC, it forms the basis of a competition for anyone who wants to test their mettle and win fantastic prizes. Anyone can enter.

    One week after the race, one winner and nine runners up will be drawn at random from the first 100 correct answers that we receive. Later this year, the lucky winner will get to jump in the Secure Racing Aston Martin Vantage GT4 to experience the exhilarating speed of getting around a circuit alongside a professional race driver. The winner will also get tickets to join the team at the Silverstone British GT Championship round and, along with the nine runners up, they will also receive complimentary membership to the Secure Racing members club – the details of which will be announced on race day.
    Anyone who attends the Brands Hatch race on 19th June will have a chance to get up close and personal with our Aston and therefore have the best chance of spotting and cracking the code. For those that can’t make it, we will be posting pictures of the car on our website a couple of days after the race so you can take part.
    Those who find and crack our code should email their answer to richard.moss@secureracing.co.uk
    Ladies and gentlemen – the fun begins here. Start your engines, the Secure Racing story is about to begin.
    Discounted admission tickets available exclusively for Secure Racing fans at: www.motorsportvision.co.uk/secracing

    REVIEW: “Making, Breaking Codes: An Introduction to Cryptology”, Paul Garrett

    BKMABRCO.RVW   20101128

    “Making, Breaking Codes: An Introduction to Cryptology”, Paul Garrett, 2001, 978-0-13-030369-1
    %A   Paul Garrett Garrett@math.umn.edu Paul.Garrett@acm.org
    %C   One Lake St., Upper Saddle River, NJ   07458
    %D   2001
    %G   978-0-13-030369-1 0-13-030369-0
    %I   Prentice Hall
    %O   800-576-3800 416-293-3621 +1-201-236-7139 fax: +1-201-236-7131
    %O  http://www.amazon.com/exec/obidos/ASIN/0130303690/robsladesinterne
    http://www.amazon.co.uk/exec/obidos/ASIN/0130303690/robsladesinte-21
    %O   http://www.amazon.ca/exec/obidos/ASIN/0130303690/robsladesin03-20
    %O   Audience a- Tech 2 Writing 1 (see revfaq.htm for explanation)
    %P   523 p.
    %T   “Making, Breaking Codes: An Introduction to Cryptology”

    The preface states that this book is intended to address modern ideas in cryptology, with an emphasis on the mathematics involved, particularly number theory.  It is seen as a text for a two term course, possibly in cryptology, or possibly in number theory itself.  There is a brief introduction, listing terms related to cryptology and some aspects of computing.

    Chapter one describes simple substitution ciphers and the one time pad.  The relevance to the process of the sections dealing with mathematics is not fully explained (and neither is the affine cipher).  Probability is introduced in chapter two, and there is some discussion of the statistics of the English language, and letter frequency attacks on simple ciphers.  This simple frequency attack is extended to substitution ciphers with permuted (or scrambled, but still monoalphabetic) ciphers, in chapter three.  There is also mention of basic character permutation ciphers and multiple anagramming attacks.  Chapter four looks at polyalphabetic ciphers and attacks on expected patterns.  More probability theory is added in chapter five.

    Chapter six turns to modern symmetric ciphers, providing details of the DES (Data Encryption Standard) as examples of the principles of confusion, diffusion, and avalanche.  Divisibility is important not only to the RSA (Rivest-Shamir-Adlemen) algorithm, but, in modular arithmetic, to modern cryptography as a whole, and so gets extensive treatment in chapter seven.  The Hill cipher is used, in chapter eight, to demonstrate that simple diffusion is not sufficient protection.  Complexity theory is examined, in chapter nine, with a view to determining the work factor (and sometimes practicality) of a given cryptographic algorithm.

    Chapter ten turns to public-key, or asymmetric, algorithms, detailing aspects of the RSA and Diffie-Hellman algorithms, along with a number of others.  Prime numbers (important to RSA) and their characteristics are examined in chapter eleven, and roots in twelve and thirteen.  Multiplicativity, and its weak form, are addressed in fourteen, and quadratic reciprocity (for quick primality estimates) in fifteen.  Chapter sixteen notes pseudoprimes, which can complicate the search for keys.  Basic group theory, covered in chapter seventeen, relates to Diffie-Hellman and a variety of other algorithms.  Diffie-Hellman, along with some abstract algorithms, is reviewed in chapter eighteen.  Rings and fields (in groups) are noted in chapter nineteen, and cyclotomic polynomials in twenty.

    Chapter twenty-one examines a few pseudo-random number generation algorithms.  More group theory is presented in twenty-two.  Chapter twenty-three looks at proofs of pseudoprimality.  Factorization attacks are addressed in basic (chapter twenty-four), and more sophisticated forms (twenty-five).  Finite fields are addressed in chapter twenty-six and discrete logarithms in twenty-seven.  Some aspects of elliptic curves are reviewed in chapter twenty-eight.  More material on finite fields is presented in chapter twenty-nine.

    Despite the title, this is a math textbook.  You will need to have, at the very least, a solid introduction to number theory to get the benefit from it.  Even at that, the application, and implications, of the mathematical material to cryptology is difficult to follow.  The organization probably also works best in a math course: it certainly seems to skip around in a disjointed manner when trying to follow the crypto thread, and apply the math to it.  For all its faults, “Applied Cryptography” (cf. BKAPCRYP.RVW) is still far superior in explaining what the math actually does.

    copyright, Robert M. Slade   2010     BKMABRCO.RVW   20101128

    REVIEW: “Codes, Ciphers and Secret Writing”, Martin Gardner

    BKCOCISW.RVW   20101229

    “Codes, Ciphers and Secret Writing”, Martin Gardner, 1972,
    0-486-24761-9, U$4.95/C$7.50
    %A   Martin Gardner
    %C   31 East 2nd St., Mineola, NY  11501
    %D   1972
    %G   0-486-24761-9
    %I   Dover Publications
    %O   U$4.95/C$7.50 www.DoverPublications.com
    %O  http://www.amazon.com/exec/obidos/ASIN/0486247619/robsladesinterne
    http://www.amazon.co.uk/exec/obidos/ASIN/0486247619/robsladesinte-21
    %O   http://www.amazon.ca/exec/obidos/ASIN/0486247619/robsladesin03-20
    %O   Audience n- Tech 1 Writing 2 (see revfaq.htm for explanation)
    %P   96 p.
    %T   “Codes, Ciphers and Secret Writing”

    This brief pamphlet outlines some of the simple permutation and substitution ciphers that have been used over time.  The emphasis is on the clever little tricks that go into making ciphers slightly harder to crack.  None of the algorithms are terribly sophisticated, and exercises are given at the end of each chapter.  Instructions are given for decrypting some of the ciphers, even if you don’t know the key.

    Two additional chapters address related topics.  The first deals with various forms of secret writing, such as invisible inks, or steganographic messages.  The last chapter briefly examines the problem of creating messages that unknown people, with unknown languages, may be able to solve (such as sending messages to the stars).

    None of the material is strenuous, but this may be a nice start before moving on to a work such as Gaines “Cryptanalysis” (cf. BKCRPTAN.RVW).

    copyright, Robert M. Slade   2010     BKCOCISW.RVW   20101229

    FBI Planted backdoors in OpenBSD IPSEC?

    Not sure what to make of this yet:

    “FBI Added Secret Backdoors to OpenBSD IPSEC”

    Theo De Raadt seems to be ambiguous about this:

    It is alleged that some ex-developers (and the company
    they worked for) accepted US government money to put backdoors into
    our network stack, in particular the IPSEC stack.  Around 2000-2001.

    […]

    I refuse to become part of such a conspiracy, and
    will not be talking to Gregory Perry about this.