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

Share

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/

    Share

    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).

    Share

    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

    Share

    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

    Share

    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

    Share

    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

    Share

    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.

    Share

    Differing takes on privacy

    UAE says privacy is a security risk.

    US says openness is a security risk.

    Share

    REVIEW: “SSL and TLS: Theory and Practice”, Rolf Oppliger

    BKSSLTTP.RVW   20091129

    “SSL and TLS: Theory and Practice”, Rolf Oppliger, 2009, 978-1-59693-447-4
    %A   Rolf Oppliger rolf.oppliger@esecurity.ch
    %C   685 Canton St., Norwood, MA   02062
    %D   2009
    %G   978-1-59693-447-4 1-59693-447-6
    %I   Artech House/Horizon
    %O   617-769-9750 800-225-9977 artech@artech-house.com
    %O   http://books.esecurity.ch/ssltls.html
    %O  http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne
    http://www.amazon.co.uk/exec/obidos/ASIN/1596934476/robsladesinte-21
    %O   http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20
    %O   Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
    %P   257 p.
    %T   “SSL and TLS: Theory and Practice”

    The preface states that the book is intended to update the existing literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security), and to provide a design level understanding of the protocols.  (Oppliger does not address issues of implementation or specific products.)  The work assumes a basic understanding of TCP/IP, the Internet standards process, and cryptography, altough some fundamental cryptographic principles are given.

    Chapter one is a basic introduction to security and some related concepts.  The author uses the definition of security architecture from RFC 2828 to provide a useful starting point and analogy.  The five security services listed in ISO 7498-2 and X.800 (authentication, access control, confidentiality, integrity, and nonrepudiation) are clearly defined, and the resultant specific and pervasive security mechanisms are mentioned.  In chapter two, Oppliger gives a brief overview of a number of cryptologic terms and concepts, but some (such as steganography) may not be relevant to examination of the SSL and TLS protocols.  (There is also a slight conflict: in chapter one, a secure system is defined as one that is proof against a specific and defined threat, whereas, in chapter two, this is seen as conditional security.)  The author’s commentary is, as in all his works, clear and insightful, but the cryptographic theory provided does go well beyond what is required for this topic.

    Chapter three, although entitled “Transport Layer Security,” is basically a history of both SSL and TLS.  SSL is examined in terms of the protocols, structures, and messages, in chapter four.  There is also a quick analysis of the structural strength of the specification.
    Since TLS is derived from SSL, the material in chapter five concentrates on the differences between SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and 1.2.  DTLS (Datagram Transport Layer Security), for UDP (User Datagram Protocol), is described briefly in chapter six, and seems to simply add sequence numbers to UDP, with some additional provision for security cookie exchanges.  Chapter seven notes the use of SSL for VPN (virtual private network) tunneling.  Chapter eight reviews some aspects of
    public key certificates, but provides little background for full implementation of PKI (Public Key Infrastructure).  As a finishing touch, chapter nine notes the sidejacking attacks, concerns about man-in-the-middle (MITM) attacks (quite germane, at the moment), and notes that we should move from certificate based PKI to a trust and privilege management infrastructure (PMI).

    In relatively few pages, Oppliger has provided background, introduction, and technical details of the SSL and TLS variants you are likely to encounter.  The material is clear, well structured, and easily accessible.  He has definitely enhanced the literature, not only of TLS, but also of security in general.

    copyright Robert M. Slade, 2009    BKSSLTTP.RVW   20091129

    Share

    Why a 27 character password is less secure than an 8 character one

    The Russians obviously did not read my earlier posts on why longer passwords are often less secure than shorter ones.
    So they forced their agents to use a 27-character password which was easily retrieved by the FBI… since it was written on a piece of paper.

    The time it takes to break a 27-character password: a few hours (going through the post-it notes and paper scraps)
    The time it takes to break an 8-character password: 242 Days (assuming uppercase/lowercase letters only, brute forcing 10,000 passwords per second).

    (via Bruce Schneier. Password recovery calculation time here)

    Share

    Examining malware will be illegal in Canada

    We’ve got a new law coming up in Canada: C-32, otherwise known as DMCA-lite.

    Lemme quote you a section:

    29.22 (1) It is not an infringement of copyright for an individual to reproduce a work or other subject-matter or any substantial part of a work or other subject-matter if
    [...]
    (c) the individual, in order to make the reproduction, did not circumvent, as defined in section 41, a technological protection measure, as defined in that section, or cause one to be circumvented.

    Now, of course, if you want to examine a virus, or other malware, you have to make a copy, right?  So, if the virus writer has obfuscated the code, say by doing a little simple encryption, obviously he was trying to use a “technological protection measure, as defined in that section,” right?  So, decrypting the file is illegal.

    Of course, it’s been illegal in the US for some years, now …

     
     
     
    Share

    The complexity of the ad-hoc network (and network research)

    After months of intermittent attempts and research, I finally have a connection between two of my laptops, and an Internet connection to the one that is not physically connected to the wired LAN.

    (Well, perhaps I might qualify that.  I appear to have a connection to the Internet, and I seem to have been successful at viewing a couple of Websites, and sending one piece of email.  It’s pig slow, and at the moment the mailer is trying to download some email.  It’s made enough of a connection to know that some email is there, but actually retrieving the email is taking enough time that I have been able to start to prep this posting in a browser window while I’m waiting.  I type very slowly, and, as of the end of this paragraph, it hasn’t yet successfully downloaded the second of seven messages.)

    (The speed of the connection [although the computer says the connection is "Very Good"] may be due to the fact that I’m using  WEP with 104, rather than 40, bit key.  Don’t know how much difference it would make.  At the moment, having only just established the connection, I’m not about to mess with the settings to find out.)

    However, as happy as I am to have the connection, the simple fact of it is not important enough to warrant a blog post.  No, the real point is all the trouble I encountered trying to find out how to make it work.  Following on from the complexity of any computing that I wrote about earlier.
    As usual, I made my own life more difficult.  If all I wanted was a simple ad-hoc wireless network, that could be had for the asking.  Well, sort of.  A simple wireless network doesn’t do very much, unless you can share information from the drives, or share an Internet connection.  And that seems to be extra.

    (Maybe.  At one point in the process, I had left one of the test wireless networks “on.”  And in one of my classes, one of my students managed to connect to it and get an Internet connection from the wired connection I had.  Random successes aren’t terribly useful, unless you can repeat them.)

    Anyway, I have a wired network at home.  I have sharing enabled, so that I can copy materials from one machine to another.  At the moment, all of them run Windows XP.  (Yeah, I know.  I’ll get around to Linux sometime …)  I have (now) multiple laptops, and have to take at least one of them on the road for teaching.  And, of course, the mobile machines have to connect to all kinds of wired and wireless connections on the road.

    Of course, the easy way would be to go to London Drugs and get a wireless router, connect it to the wired LAN, and fill in a few simple settings.  It’d probably take no more than a couple of hours, from beginning to end.  But I wouldn’t learn much about ad-hoc networking that way, and I’ve been getting more interested in it, particularly as a security concern, as I have been seeing that “computer-to-computer network” legend show up in more and more places.  (Especially with “Free Internet Connection!” as the network name.)

    So, having a spare laptop (since, on a recent teaching trip, it decided to go spare on me), I figured it would be easy to set up a connection between that and the new one.

    Actually, it was on the trip that I wanted to start the process.  There was nothing wrong with the old laptop (except that it was a Toshiba, and I’ve had two Toshibas in a row, and I will never again by anything made by Toshiba since they’ve given me nothing but grief for eight years) except that the power supply was becoming unreliable.  I bought a cheap (and non-Toshiba) netbook and asked for advice about connecting them via ad-hoc network in order to transfer the necessary files.

    Well, lots of advice, but nothing actually worked, and I fell back on using the Passport external drive my wonderful daughters gave me that has been so useful in so many situations.  But it doesn’t do networking.

    The friends gave me some starting points in terms of places to look for advice.  Microsoft, naturally.  There is a wonderful page at http://www.microsoft.com/windowsxp/using/networking/expert/bowman_02april08.mspx which provides clear explanations.  Only a couple of problems: it was written in 2002, so the dialogue boxes have changed.  This piece does talk about sharing an Internet connection, but it doesn’t mention the need to modify the default IP addresses, since everything seems to want to use 192.168.0.1 as a base, and that leads to conflicts.  Bottom line: it doesn’t work.

    Microsoft updated the information in 2006 at http://www.microsoft.com/windowsxp/using/networking/setup/adhoc.mspx and the dialogue boxes are closer to what you’ll actually see these days.  After running through that one I tested it out, only to find that the network never does show up on “Available Wireless Networks.”  I’m not sure if this is because, if you choose WEP, and tell it not to broadcast the key, it keeps it hidden.  I did manage to connect to the network, and even seemed to be able to see other computers drives, and see something of the Internet, but all of the connections disappeared over time.  Again, this page says to use Internet Connection Sharing, but doesn’t provide the necessary detail to make it work.

    All kinds of pages are out there, if you do a Web search, seemingly based on this same, limited, misinformation.  At http://www.home-network-help.com/ad-hoc-wireless-network.html the author seems to have given some thought to the issue of IP addresses, but not much.  http://www.home-network-help.com/ics-host-computer.html goes into a bit more detail on the IP addresses, but not enough, particularly in terms of the entries that have to be made in various places on various machines.

    Finding all the places to make those entries is a trip in and of itself.  The Help and Support Center for XP Home Edition is no help.  At one point I was afraid that the multitude of entries for the various networks I’ve connected to in hotels, airports, and seminar hosting sites had something to do with it, so I went and deleted all of those “Preferred networks” I had accumulated over the years.  (Did you know that they were all still there?)

    Lots of people are willing, and more than willing, to provide the benefit of their lack of experience.  I say this, since so many of the entries don’t actually work.  http://www.ehow.com/how_6108229_make-wirelss-internet-_ad_hoc-wireless_.html  Terse, doesn’t work.  http://www.ehow.com/how_5167281_create-ad-hoc-wifi-network.html  Slight tech detail, doesn’t cover sharing drive or Internet connection, doesn’t explain how to make new wireless network visible to “View available wireless networks.”  http://www.ehow.com/how_5154137_create-ad-hoc-network.html  A touch more detail than above (5167281), mentions need to share Internet connection, mentions a dialogue button that doesn’t exist in the XP explanation.  http://www.ehow.com/how_5946176_set-hoc-network-windows-xp.html  Some detail on setting up the network, doesn’t completely work, nothing on sharing.  http://www.ehow.com/way_5492555_ad-hoc-network-tutorial.html  Some detail on setting up the network, doesn’t completely work, nothing on sharing.  http://www.ehow.com/how_5670567_set-ad-hoc-wireless-network.html  Some detail on setting up the network, doesn’t completely work, nothing on sharing, does do XP and Vista.

    Some of the advice is contradictory.  For example, I mentioned I was using WEP.  This is because some of the sites, such as http://www.hardwaresecrets.com/article/418 and http://www.tomshardware.com/forum/28615-42-networking-security-problem suggest that WPA and WPA2 can’t be used if the “host” for your ad-hoc network is running Windows XP (which mine is).  Of course, that might be old news, which might have been superceded by intervening upgrades.  But, with this level of information, how am I supposed to tell?

    We are awash in a sea of information.  Except that some of the information is misinformative.  As John Lawton stated, the irony of the information Age is that it has given new respectability to uninformed opinion.  This can have rather significant consequences.  A recent CBC story notes that this may play into the May 6 stock market mini-meltdown.

    So far, the best clue I received was from http://www.wi-fiplanet.com/tutorials/article.php/3822651  I had frequently seen the “Bridge connections” option, but I somehow never thought to have two networks “selected” when I tried it.  Even then, I might have missed the opportunity.  I got the usual error message, but it suddenly dawned on me that ICS might conflict with it.  (Given that everybody else had been telling me to turn ICS on.)  So, I turned ICS off, and, sure enough, Bridge connections was happy to do just that.

    I still have no clue what has been set, and where …

    Share

    Vanishingly small utility …

    This system has had some discussion in the forensics world over the past few days.  Here’s an extract from Science Daily:

    “Computers have made it virtually impossible to leave the past behind. College Facebook posts or pictures can resurface during a job interview. A lost cell phone can expose personal photos or text messages. A legal investigation can subpoena the entire contents of a home or work computer. The University of Washington has developed a way to make such information expire. After a set time period, electronic communications such as e-mail, Facebook posts and chat messages would automatically self-destruct, becoming irretrievable from all Web sites, inboxes, outboxes, backup sites and home computers. Not even the sender could retrieve them.

    “The team of UW computer scientists developed a prototype system called Vanish that can place a time limit on text uploaded to any Web service through a Web browser.

    [Perhaps a bit narrower focus than the original promise, but it is a prototype - rms]

    “After a set time text written using Vanish will, in essence, self-destruct.  The Vanish prototype washes away data using the natural turnover, called “churn,” on large file-sharing systems known as peer-to-peer networks. For each message that it sends, Vanish creates a secret key, which it never reveals to the user, and then encrypts the message with that key. It then divides the key into dozens of pieces and sprinkles those pieces on random computers that belong to worldwide file-sharing networks. The file-sharing system constantly changes as computers join or leave the network, meaning that over time parts of the key become permanently inaccessible. Once enough key parts are lost, the original message can no longer be deciphered.”

    However, given the promise to clean up social networking sites, and as I started to read the paper, an immediate problem occurred to me.  And, lo and hehold, the authors admit it:

    “We therefore focus our threat model and subsequent analyses on attackers who wish to compromise data privacy. Two key properties of our threat model are:
    1. Trusted data owners. Users with legitimate access to the same VDOs trust each other.
    2. Retroactive attacks on privacy. Attackers do not know which VDOs they wish to access until after the VDOs expire.
    The former aspect of the threat model is straightforward, and in fact is a shared assumption with traditional encryption schemes: it would be impossible for our system to protect against a user who chooses to leak or permanently preserve the cleartext contents of a VDO-encapsulated file through out-of-band means. For example, if Ann sends Carla a VDO-encapsulated email, Ann must trust Carla not to print and store a hard-copy of the email in cleartext.”

    So, this system works perfectly.  If you only communicate with people you trust (both in terms of intent, and competence), and who only use the system properly, and never use any of the information in any program that is not part of the system, it’s completely secure.

    How often have we heard that said?

    The default to privacy aspect is interesting, and the automatic transparency for the user as well, but this simply moves the problem one step back, as it were.  In terms of utility to social networking, the social networks would have to be completely rewritten to adher to the system, and even then it would be pretty much impossible to ensure that nobody would have the ability to scrape data and keep or publish it elsewhere.

    (Plus, the data is still there, and so is Moore’s Law …)

    Share

    Offensive-Security WPA Rainbow Tables

    The guys over at Offensive Security have released a 49 Million WPA optimised password dictionary file, the torrents are up at this link here.

    If you download it though, please keep the torrents seeding for a while to help others out.

    Have fun cracking!

    Share

    The oldest vulnerability is known – let’s find the oldest data loss incident

    The oldest documented vulnerability in computer security world is password file disclosure vulnerability from 1965, found by Mr. Ryan Russell.

    Open Security Foundation – an organization behind OSVDB and DataLossDB has launched a competition to find the oldest documented data loss incident.

    The last day to make a submission is next Friday – 15th May.
    The link is easy to remember – datalossdb.org/oldest_incidents_contest.

    Share