Frontpage          Newsfeed          Search     

AnoBBS - encrypted bulletin board system v. 1.0
After developing the AnoChat in November 2007, I wanted to test the concept further by creating a whole suite of encryption products. The result is the AnoSuite, which centers around the AnoChat and the new AnoBBS, a bulletin board using Ajax and encryption to enhance the privacy of the online debater. The AnoSuite will be released later in 2009, this is the release article for AnoBBS.

The purpose of AnoBBS was to provide a simple BBS for online encrypted debate. It should be easily available and usable without any prior security knowledge or installment of additional software, either on client or server. The AnoBBS requires only a standard php distro and javascript-enabled browsers to run.
Published: 18.04 - 2009 20:21Printer version    

Downloads at the bottom of this article

Visit the AnoSuite usergroup on Facebook

The idea
To provide a group of people access to private communication encrypted by a phrase known only among the group. The conversation should be in form of a Bulletin Board, or internet forum if you like. Thanks to the ingeniouity of the hashing routine MD5 and it's irreversibility, we can use the same phrase both as encryption key and as public search id for the BBS.
Since all content encryption is done by Javascript before submit and all decryption is done by Javascript after load, the key itself will never be transmitted over the net.
The server won't know the encrypted strings as it stores encrypted content only.

The skeleton functionality
The AnoBBS uses genuine Ajax; Javascript, XMLHttpRequest and XML. This as opposed to the AnoChat, which uses 'Cheat Ajax', or as I've now dubbed it: JX (Javascript eXecutable).
The AnoBBS has the form of a web application, which never reloads the page. This makes it possible to store keys for encryption in the page after first load.
All communication to and from the server are done by Ajax calls transmitted to PHP scripts, which handle all server tasks*. The storage format is XML.
All human data is encrypted by Triple DES (3DES) and stored in encrypted form in the XML files.

* Not the BBS search, which is performed by the same technology as the AnoChat - JX.

The useability and functionality
The AnoBBS is not meant for each forum to grow into public communities with hundreds or thousands of users, it's a small refuge for people who need to debate in privacy. As it will appear to the user, it's a pretty standard looking board with the vital functions needed for online debate. Below is a list of the basic functionality:
- user authentication
- topic list and topic view
- three userlevels; admin, moderator and user
- post threads
- post and edit replies
- print or save threads
- edit, delete and lock threads (mod)
- edit forumdata and users (admin)
- save BBS (admin)
- delete BBS (admin)

The idea was to have quick access, and with the knowledge of the code phrase any user can enter a BBS by doind the following:
- search for code phrase
- click on desired skin to start BBS window
- type in code phrase in window
- log in using username and password

The log on process is also the registration process; if the user exists it will perform authentication, if not it will register the user as new user.
As opposed to the AnoChat, there is no time limitations to a created debate forum; it exists until the admin deletes it.

How to start a new BBS community

Go to the search page and type in your code phrase. You must have agreed beforehand of what this is to be and you, the group, has the responsibility to distribute the phrase in a safe way. How you get the key out to your users is not a part of the AnoBBS routine, we assume that the group in question have it already.


anobbs_authocdes.jpgIf the BBS exists, it will let you log in, if not, you will be asked if you want to create a BBS. Select the desired skin to open the BBS window. You will have to type in (or paste) the code phrase again to start the authentication.

When the auth code is set, the login form is fetched in encrypted state from the server, loaded and decrypted.

anobbs_loginforms.jpgAuthentication are performed by a pretty complicated process, involving several values. You can read more about it further down this page, but I can say that the security is pretty good and totally over the top for this use really.
The safety lies in the encryption key, supposedly known only to an intimate group. The sole purpose of the auth is to prevent anybody of those users to try take over your identity, which is unlikely. But I wanted to write the fastLogin over to Ajax to see how it worked, so this is basically a version of that authentication  software, adjusted to work with XML files (instead of a database).

The login works both like a registration and a login, so if your user don't exist in the main BBS XML file, it will reg you as a new user with the supplied credentials. If you don't want a password, leave the field empty on first login.

anobbs_startbbss.jpgIf you are the first user, you will see this screen after logging in. No topics, forumdata not set. The first user will have admin level, and access to edit of the forum data as well as user treatment.

We'll proceed to set the forumdata first.

There are four fields used for setting the forum data, forum name, group name, forum description and group description.
When set it will be the headline on top of the BBS page.

We proceed to post the first topic.

anobbs_posttopics.jpgEvery user has the right to start topics. Moderators and admins also has the right to edit topics, and delete threads.
The writing form has many functions, it is a version of the DU-O-Matic Codificator, so the format used for storage is DC-board format.

The writing form has autowrapping of text by one click and you may also use smiles.

If you just post a link, it will be converted to a clickable link, if you post a picture, it will be automatically linked into your post.

anobbs_posttopic2s.jpgThe topic is finished and posted. The title, text and your username is encrypted before submit and sent to the server, where it is stored in encrypted form.

anobbs_topiclists.jpgThis is the topic list, where the topic now is visible. A click on the topic title will lead to the view on the previous screen.

It will now be visible to other users logging on.

anobbs_viewtopics.jpgHere blogster has logged in, and is reading the topic. Of course, it looks a bit different as he has chosen another skin, but the content is the same as in mogster's window.

How to installUnzip file to directory locally.
It should produce a directory called anobbs_x.x, containing two directories: progs and root.
The root directory is the web root for your AnoBBS. Upload the directory to the desired location.

The progs directory should ideally be placed outside the document root path of your system, if you place it inside be sure to change it's name.
Upload the progs directory to the desired path, then make the directory progs/bbs world writable, or change the owner recursively to the webserver user.

Set writable:
chmod 777 /path/to/progs/bbs
Change owner:
chown -R webserver-user:webserver-group /path/to/progs/bbs

Then edit the config.php to match the pathing of your system.

When done, save the config.php and upload it to the root directory.

Now you can access the install.html and check if your installation is done.

When checked OK, remove the install.html and the anobbs_install.php. Do not access the anobbs_install.php directly to install, it is a return script for the install.html ajax calls.

The scriptsThis is the directory layout, seen in windows:

structure.jpgThe progs directory holds all included functions, and also has the bbs directory where the bbs folders are created. This need to be writable by the web server user.

The root directory has all the graphics, javascripts and also the PHP scripts to respond to the Ajax calls. It also has the skin directory called bbs.

Here is a list of the scripts used.

Progs directory
bbs_auth.php - the main run control switch for the authenticated user
bbs_uauth.php - will be deprecated in next version, returns login forrm
bbsFunctions.php -  the main functions for the BBS
tripleDes.php - the PHP 3DES function
xAuth.php - the authentication function
languages/en/bbslang.php - language file for the AnoBBS

bbs.xml - the XML template for the forum
err.xml - XML template for error return
topic.xml - XML template for topic

loginform.html - HTML template for login form
save.html - the skeleton HTML template for saving forums

Root directory
anobbs.php - the main return script for the forum window
anobbs_install.php - the return script for install.html
anochoice.php - the load file for BBS search form in main window
config.php - the configuration file. All settings are edited here
q.php - the script for auto search for BBS by direct url
sbbs.php - the return script for search for BBS in main window

index.html - the index file, it all starts here
install.html - the installation checker, will make calls to anobbs_install.php

anobbs_print.css - the stylesheet for print thread. These styles is also included in the saved versions of topic and forum
anochat_iterapi.css - stylesheet for main window

Javascripts in js/:
anobbs.js - the main javascript running the BBS
anobbs_mainwin.js - the javascript for the main window
anobbs_save.js - the javascript to be included in saved versions of forum and topic
anobbs_vars.js - the variables javascript: language and settings
anochat_system.js - the system functions
md5.js - the md5 hashing javascript
tripleDes.js - the 3DES function as javascript

Templates in tpl/:
bbs.html - the template for the search form

Some example filesAll BBS content is stored in encrypted state in XML files at the server. First some examples on run time XML. All files are stored in the forum directory, created in /path/to/progdir/bbs/ when the BBS is initiated.

This is the forum file:
AnoBBS forum example
It contains an upper section with forum name and settings, then continues with user sessions, then registred users, and ends with a list of the forum topics.

The topic section of the forum file will link in the next XML example file, the live topic:
AnoBBS topic example
Roughly, this consists of an upper section with topic settings and OP, then continues with the topic replies. The post texts is broken up into 2000 char sections, as Ajax has some problems with huge strings in one child node.

Each topic will have it's own XML file, named like this:

-rw-r--r-- 1  986 Mar 16 18:59 1_a170c8a1678944bd2c07652ce2418181.xml
-rw-r--r-- 1  25K Mar 16 21:38 2_a170c8a1678944bd2c07652ce2418181.xml
-rw-r--r-- 1 1.2K Apr  6 16:33 3_a170c8a1678944bd2c07652ce2418181.xml
-rw-r--r-- 1 1.1K Apr  7 19:37 4_a170c8a1678944bd2c07652ce2418181.xml
-rw-r--r-- 1  778 Apr 12 17:25 5_a170c8a1678944bd2c07652ce2418181.xml
-rw-r--r-- 1 5.0K Apr 13 14:02 a170c8a1678944bd2c07652ce2418181.xml

The file not prepended with an integer is the main forum file, and these files is inside a folder named a170c8a1678944bd2c07652ce2418181.

Basically, the info stored in the XML files are encrypted strings, md5-hashes and timestamps. Not all fields are used, I made some reserved for future use.

Besides having the run time xml, the AnoBBS also creates it's own HTML files on Save Thread (all) and Save BBS (admin only). Here's an example on a saved topic:

This is the exported topic file:
AnoBBS saved topic example (63 KB)
The key for decryption is bbsdesign
It contains all encrypted strings from that topic stored as Javascript XML variables and the 3DES Javascript function needed to decode it. It only need the key to decrypt the strings. The input code validates against a stored value in the XML (the BBS ID) by doing a triple MD5 on the typed in text. Try View Source to see the XML-strings embedded in the code.
The design is stripped to make it portable through email, no pictures are embedded and the styles are shaved down.

Even cooler, the BBS itself can be stored, and sent like a standalone HTML file. It is even browsable once decrypted. This is the Save BBS export:
AnoBBS forum export example (84 KB)
The key for decryption is bbsdesign

This is how the forum-data is stored in the page above: as XML strings.
AnoBBS XML strings from saved forum (25 KB)
Upon decryption, they are loaded through the loadXdoc(xmlstring)-function, and are accessible for browsing just as if the forum was online.


The phrase is 'i love my thick fleece jacket'. This is our clear text key, which we must remember and type in when we search for a BBS.
When search is submitted, the script returns either an offer to create a new BBS or the one you searched for, if it exists. Before sending the data, it makes a triple MD5 on the code you entered. That is the QUERY as it is transferred over the net in a public query.
When you start the BBS window, the code phrase must be entered again, and as you click 'Set auth code', the encryption keys are created from the code.

Breakdown, key generation from code phrase

There are five states of your code phrase:

'i love my thick fleece jacket'
This is the clear text code phrase which is used for both search and encryption. It is the only thing the user need to remember. It is not used as itself, only for generating the other keys.

The once md5 of the code phrase. We name this key K1. This is in the private domain, is never transmitted and used for the end-to-end encryption of the content.
In this case the security contract is between the users in the group, the server does not know this key. The content is encrypted by each client and decrypted by each client.

The twice md5 of the code phrase. This is in the private domain, but is transmitted once over the net (in obfuscated condition) when the first user logs in to the BBS, and is stored in the BBS XML file. It is the forum key, and is used for encryption between the ajax client and the PHP server. All authentication data is encrypted before transmit by javascript using this key, and decrypted by PHP using the same key. We name this key K2.
In this case the security contract is between each client and the server. The content is encrypted by each client and decrypted by the server.

The triple md5 of the code phrase. This is the search ID used to find the correct BBS, it is in the public domain. This is not an encryption key, but the query ID, so we name it QUERY.

These are all created by javascript before request and only the QUERY is transferred over the net, the two others are stored in the page and used as encryption keys. The non-reversible characteristics of md5 let's us create several keys which are not related to each other at all.

When the query ID comes to the server, PHP does another md5 on it before using it to look for the right BBS:

This is the fourth md5 of the code phrase, and is in the public domain. It is used as a name for the directory which contains the BBS and also is the name of the forum file.
This value is named BBS ID.

Breakdown, encryption

We have two types of encryption going on in the AnoBBS page; the content encryption and the authentication encryption. They use different keys, and different methods.

The content encryption is done with the key K1. With content we mean all human data, like names, nicks, topics and posts and forum name/group data. The key K1 will only be known to the group, and the method will be end-to-end encryption.
End-to-end encryption means the server does not know the key and just stores the encrypted lines, which are loaded by another Ajax client and decrypted by javascript, using the key stored locally in that page.

The authentication encryption uses the key K2.
With authentication data we mean passwords that is encrypted under two conditions: when the user registers and every time when the user logs in. The K2 is sent over the net once; when the first user logs in for the first time. We try to amend by using the QUERY as key and encrypt the K2. Once transferred, it is decrypted by PHP and stored in the XML file.

Both methods uses Triple DES (3DES) encryption. The scripts used is located here.
New in AnoBBS is a new PHP 3DES function from Tero's site that is much quicker than the previous function, written by me. You can test the difference here, please be adviced that it takes some time to process this script. The result is smashing: a string taking 6 seconds to encrypt using the new script takes over 30 seconds using my 2002 outhacked code, which was written from that javascript function and the perl function Tero also had. I sweated extensively over that piece of code and it isn't surprising that it did slow work ;-)
And neither did it work on 64-bit arch, as this example shows, while on i386 it works.

With PHP encrypting/decrypting this fast and effortless, it can be interesting in later versions to make PHP take more of the encryption job, maybe even make a client-to-server encryption version.

Note on encryption:
Images and linked elements will not be encrypted, that is impossible with Javascript. The encryption is performed on the text only.

The encrypted/transferred values and login process, chronologically:

In main window:
Upon load, the search form is loaded in encrypted state. The key is randomly created by PHP and is transmitted with the form (public).

On search, no values are encrypted or sent other than the triple md5 of the code phrase (QUERY ID), which is in the public domain. The return is encrypted by PHP using a randomly generated key, which is sent with the form (public).

On Create BBS, the double md5 of the code phrase (K2) is encrypted with the triple md5 of the code phrase (QUERY ID) as the key. (public). The return from Create BBS is encrypted with a randomly generated PHP key, which is transmitted with the form (public).

Two values are transferred into the BBS forum window from the encrypted return from Create BBS and Found BBS; the publicly known query id and a session id for session authentication.

In forum window:

The code phrase for auth is md5'ed into three values, each a md5 of the previous, and stored in the page for use in encryption/queries. On set auth code, the session id and the query id is sent to query for the login form. It is encrypted by PHP with the value of md5(K2 auth key + session id) as key before transferred back to the browser (private). Enclosed in the form is the md5 of the clients ipaddress and the md5 of the clients browser string.

On login, the following values are produced pre-submit:
cpc  - the crc check - which is the value of md5(query string+'^'md5(typed in user name)), encrypted with the K2 key (private). It will be used to check the coherency of the encryption and login process.

A hash fragment is put together from the md5'ed ip and browser string together with the session id, and made as md5(ip+browserstr+sessid). It is then further built with adding the values of the login form into the final hash:
dHash = md5(username+':'+password+':'+hash frag)
This is the auth compare hash for authentication.

tcuser - the user name encrypted with the private key K1 (private)
transpass - the user password encrypted with the K2 key (private). It needs to be decryptable by the server.

The login routine is basically repeated on each page refresh, except that another value is introduced into the dHash: the exec, which is the micro session control hash.
This introduces randomness and session control to the auth. Read more in next chapter: Breakdown, authentication.

When debating, all human understandable values are encrypted using the K1 key:
Forum name, group name, forum description, group description, user names, topic header, topic text, reply header and reply texts. See example XML files later in article.

Breakdown, authentication

First, the authentication used here is totally overblown in level of security as all it should do is protect your identity and integrity as a poster in the group - meaning nobody else can post as you because your 'account' is password protected. Due to the nature of the AnoBBS and how it works with a shared group key, we assume that you know these people pretty well so in reality the auth shouldn't be necessary. The first testversion of the software had no auth at all, only a nick to identify you in the group, much like the AnoChat. But I realized that people may be have a bit more ownership to the content they post on a bulletin board, so there you go. I also wanted to write the auth fastLogin into Ajax, to test. The authentication used here is more or less a blueprint of fastLogin 2.5 with microsessions, a soft authentication I wrote between 2002-2006.

Let's take the auth sequentially:

The login starts already when you search for a BBS. If it exsists, a session will be registred for you in that XML file. If it does not exist, it will create a XML file with a user session in it. The session ID is a random generated md5 hash by PHP, and will return as a variable in the skins onclick javascript event, then written into a hidden field in the BBS window. Thus, a link between you and the BBS file exists. The XML snippet in the file at this point looks like this:

 <acusersesstring>4aebbf05d197ec55144b4... (480 chrs)</acusersesstring>

The values stored are as follows:
acusersessionid: The users session ID. It stays the same for as long as the user is in the same BBS window, and doesn't log out.

acusersessionauth: The users session auth. This is a md5 of   $_SERVER values collected by PHP; ip address and user agent, and your seed (the above value). The ip address and the user agent are md5'ed before use.

acusersessname: This is the user's encrypted name when inlogged. At this point it is not set.

acusersesstime: The check-in time as unix timestamp.

acusersesstring: The microsession string. It contains 480 chars, which is made out of 15 32-char md-hashes. One 32-char has will be cut of the beginning of the string on each request (page 'load') and a new 32-chars auth hash added to the end of the string.
This string will change every time the page loads Ajax content, and secures against replay attacks and session hijacking. Every auth hash has thus a lifetime of 15 refreshes before it expires. The new hash is sent by Ajax to the client on each reload, and stored as the value of the hidden field 'exec'.

This is how your contract with the server looks after having done a BBS search:
- you have a unique ID stored in each skins onclick event and replica on the server
- you have a light auth based on the presence of your ip address and user agent in the xml file as you proceed into the BBS window.

Starting the window
The window is a child created of the index.html and has no url of it's own.

When it starts, the session ID is written into a hidden field and it displays the field for setting the auth code (code phrase). When set, the code is written into a hidden field, and it triggers an Ajax event which will load the login form. The form is Triple DES encrypted by PHP using the md5 of the forum key + the users seed (acusersessionid), the same values are used to decrypt the form by javascript on load. Inside the form are two values in hidden fields: the md5 of your ip address and you user agent string.

So, we have the session ID, the md5-ip, the md5-user agent. We only need your user name and your password to compose a comparison hash for check against the XML file and log you in.
The login works both as a user registration and a login. If the user exists, we control his values, if he doesn't exist, we create a user with the submitted crendentials.

The function creating the auth on the client side looks like this:

function dolocalAuthx() {
// Get cleartext nickname
var uxfieldval = getElement("setnick").value;
//Get name of destination field for encrypted nick
var uxcfieldval = getElement("nick");
// Get sessidkey from loginform
var uxsesskey = getElement("sessidkey").value;
// Get clear text password from login form
var uxfieldpass = getElement("setpass");
// Get name of field for password storage
var uxfieldacpass = getElement("acxpass");
// Get exec (this has actually a hard coded value at this time: srq)
var exc = getElement("exec").value;
// Do md5 on the password. That is the real password
var uxfieldpassflp = MD5(uxfieldpass.value);
// Store the md5'ed password locally
uxfieldacpass.value = uxfieldpassflp;
// Get encryption key (K1)
var txkey = retK();
// Encrypt the user's username
var doUcrypt = des(txkey, C2E(uxfieldval), 1, 0);
// Store the user's encrypted username as hex in the hidden field 'nick'
uxcfieldval.value = printHex(doUcrypt);
// Get the query id (QUERY)
var tque = retCD();
// Get the user's encrypted name, for auth
var tcuser = retY();
// Produce dummy, has no purpose but to help avoid caching
var xdummy = retDummy();
// Get auth encryption key (K2)
var cpkeyx = retCP();
// Construct string for CRC check and encrypt it using the K2 key
var crcstr = MD5(MD5(tque)+'^'+MD5(tcuser));
var doCRCcrypt = des(cpkeyx, C2E(crcstr), 1, 0);
var cpc = printHex(doCRCcrypt);
// Encrypt password using the K2 key
var doPASScrypt = des(cpkeyx, C2E(uxfieldpassflp), 1, 0);
var transpass = printHex(doPASScrypt);
// Set the visible username in window
var xunameset = getElement("authrightfloat");
xunameset.innerHTML = uxfieldval;
// Fetch client ip as md5 from loginform
var uxip = getElement("sessip").value;
// Fetch client useragent as md5 from loginform
var uxagent = getElement("sessagent").value;
// Make hash fragment for further compilation
var dHashfrag = MD5(uxip+uxagent+uxsesskey);
// Create response hash for comparison at the server
var dHash = MD5(uxcfieldval.value+':'+uxfieldpassflp+':'+dHashfrag);
// Make final url out of all the values to send to the Ajax engine, and to the server
var urltx = urlbs+'?c=blx&q='+tque+

The chkAuthdatax(url) function does the Ajax call.
When the data is arriving at the server, PHP does a check first in the anobbs.php whether the user exists after gathering the incoming values (I have simplified the code a bit for this article):

## c = switch state ##
$c = cleanC($_GET['c']);
## x = user nickname, encrypted ##
$xuser = isHex(strip_tags($_GET['x']));
## q = BBS id, three times md5 of BBS code phrase. We use it as control value on the client side, ##
## and md5 it once more for security, to use in the file creation and server side. First a check: ##
$djsret = is_md5($_GET['q']);
$dcodesearch = md5($djsret);
## Get seed
$ss = is_md5($_GET['s']);

## If login mode
if($c == "blx") {
$fk = trim(ret_xmlfield("acforumkey", $retcontx));
$factiveadmin = trim(ret_xmlfield("acforumadmin", $retcontx));
$cUser = chkUser($xuser, $retcontx);
$xcpass = isHex(strip_tags($_GET['pk']));
## If user does not exist, create user
if($cUser[0] == 0) {
$pbinfrag = hexToString($xcpass);
$xpass = trim(TripleDES($fk,$pbinfrag,0,0,$iv));
if($cUser[1] == 1) {
$retcontx =  retnxUser($xuser, "admin", $xpass, $cUser[1], $retcontx);
if(ret_xmlfield("acforumadmin", $retcontx) == "^ACFORUMADMIN^") {
$retcontx =  put_xmlfield("acforumadmin", $retcontx, $xuser);
$retcontx =  put_xmlfield("acforumadminpass", $retcontx, $xpass);
} else {
$retcontx =  retnxUser($xuser, "user", $xpass, $cUser[1], $retcontx);
} else {
$retcontx = updUser($xuser, $retcontx, "");

If the user does not exist, it will create the user then log the user in through the next step.

## Include the authentication function ##
/* Get some vars needed for comparison
$cpc = the CRC check, encrypted with the CP key (forum key) | hex
$dhash = the main comparison hash. It changes every time the page loads | md5
$e = the previous $trigger, used in the calculation of the hash above | md5

$cpc = isHex($_GET['cpc']);
$dhash = is_md5($_GET['dh']);
$exec = $_GET['e'];
if($exec != "srq") {
$execute = is_md5($exec);
} else {
$execute = "srq";

## Declare empty values ##
$retHash = "";
$uLevel = "";
$trigger = "";
$runcontrol = "";
$retcontxt = "";
$retcontfillarr = "";

## Run the auth function, it returns a six piece array ##
$retcontfillarr = xauth($xuser, $dhash, $dcodesearch, $ss, $execute, $cpc, $retcontx);
## The return hash for comparison ##
$retHash = $retcontfillarr[0];
## The users userlevel ##
$uLevel = $retcontfillarr[1];
## The microsession trigger ##
$trigger = $retcontfillarr[2];
## The value $ss is now filled into the value $seedz
$seedz = $retcontfillarr[3];
## The run control, controls which type of action we are allowed to take: login or runtime
$runcontrol = $retcontfillarr[4];
## The return of the treated xml ##
$retcontxt = $retcontfillarr[5];
## We prepare an error string for errors ##
$reterrstring = "\n\n\t^ERR^\n";

## Start checking auth, do we have the seed? ##
if($seedz != "") {
## If seed is present do comparison ##
if($retHash != "" && $retHash == md5(md5($xuser) . $seedz  . $trigger)) {
## Here be auth ;-)

## The outer switch, decided by the return from the xauth function
switch($runcontrol) {
## Treatment on login
case "login":
updateBBS($bbsfiledir."/".$dcodesearch."/".$dcodesearch.".xml", $retcontxt);
$retcontxt = filterXML($retcontxt);
$retcontxt =  put_xmlfield("acforumtstamp", $retcontxt, time());
$retcontxt =  put_xmlfield("aexec", $retcontxt, $trigger);
header("Content-type: application/xml");
echo $retcontxt;

## Treatment for inlogged - this is where the action is ##
case "runtime":

(Removed here)

} // End switch
} // End auth
} // End seed check

Know your encryption!You are not safe if you don't understand a minimum of the basic principles about encryption. I strongly urge you to look at this software as strong obfuscation, not in the same class as stream encrypted material (SSH, SSL). But you can use the AnoBBS over an encrypted connection, I have tested with apache mod_ssl and it works fine.

Encryption is the same everywhere it is used, but to encrypt a flowing stream of data is much more safe compared to just encrypting dedicated strings, like the AnoBBS does. Much can be assumed about the data in question by reading the metadata for the xml containers which the crypts are delivered by. A term used in breaking encryption is known plaintext attacks, in which an adversary has knowledge of, or can guess, some of the plain texts which are encrypted, and may use that knowledge to break the encryption by comparing the encrypted strings.
I am contemplating in later versions to include random padding of repetitive strings, like usernames, so as to make this more difficult.

The AnoBBS is an attempt on improving upon your privacy over open protocol, http, not a system for nukular secrets. It focuses on accessibility of lightweight encryption for communication about topics which you want to keep in private.

Yet, the AnoBBS does provide a safe guard of your text:
- all human identifiable information is strongly obfuscated so as to bring it out of the eyes of autosniffing systems which trigger on key words, phrases etc.
- if one wishes to break the encryption, the key is not known and the crypt must either be either cracked by brute force or the key must be found

One of the strongest advantages with the end-to.end encryption is that it makes proxied man in the middle attacks more difficult. A proxied MITM is in this respect a situation where you have a forced proxy installed on your gateway or at least awfully close to home, if you get my meaning.
Yeah, the 'Dirty ISP' scenario ;-)
To get to know the key for such an attack when it is typed into a form after page load, and never submitted over the net, is difficult. The content is encrypted the moment it leaves your browser, and is not decrypted until it is inside another browser, where the key is fetched from a field in the page, typed in by that user after he's loded the page.
To work around this, the adversary must change the code you recieve to your browser before it reaches the browser, including a javascript which sniffs the text field where you type your code phrase. It would be pretty exotic, yet maybe possible.
I've foreseen this and try to amend by encrypting the form where the code resides before sending it from the server, and the field itself uses a so-called 'nonce' to further make it difficult to get to the field, and also to turn off auto-completion. The code for decrypting the code form is known and propagated in the same xml-snippet wich returns the encrypted form, yet in order to hack around this, the adversary must:
- get hold of the xml return, and pick out the key
- decrypt the code form and get the field code
- rewrite the html and then return as encrypted hash as xml thru proxy rewriting or other means to include a sniffer script
- send the xml to your browser

There are two terms used in this description which can be confusing; md5 and 3DES.
Md5 is a hashing routine which creates a unique hash from a phrase, i.e. 'i love my warm fleece jacket'. The result would look like this:
This hash is used as key in the encryption, and is not in itself an encrypted string.
A hash is irreversible, so it would serve no use as a means of communication because it does not 'decrypt' back to the original. It's always 32chrs long.

An encrypted string of the same phrase would look, for example, like this:
It would depend on the key used, a different key would produce an entirely different string.
This string looks about the same as the md5-hash, but that's because it is hex encoded for easier transport. It contains hidden text, encrypted with 3DES, which is reversible into a clear text phrase, if you know the key.

DES/3DES (Data Encryption Standard) is the previous encryption standard, the current is named AES (Advanced Encryption Standard). The AES is available as Javascript, but I haven't seen a standalone PHP function yet. Still, it could be interesting to test the K1 encryption with AES in a future version of the AnoBBS.
As it is, 3DES is still widely in use and considered good until 2030.

Some snapshots from a network sniffer:

anobbs_sniffer1.jpgA request for the forum topic list returns as XML, with values encrypted and hex-printed.

anobbs_sniffer2.jpgA request for topic returns as XML, with values encrypted and hex-printed.

DownloadsDownload the AnoBBS here:

AnoBBS version 1.0.1 XML
MD5 verification: 0da180bfdbfdb57a54113a86bf9090ab

Listed at Hot Scripts Listed in HotScripts

############### NO WARRANTY ############################
The creator of the AnoBBS does not guarantee the safety of your data, and you use the scripts at your own risk. The author is not to be held responsible for any losses due to the use of these scripts
This is an attempt to improve on your privacy under open protocol http and if you are in need of serious security, you should use stream encrypting systems like SSL.
The AnoBBS uses end-to-end encryption, meaning the key is not transferred over the net. The propagation of the key to participants is not a part of the script routine.

The AnoBBS is published with a GPL license.

 facebook    digg    reddit    furl   



Peace demonstrations in the US October 26-28 2007
29.10 - 2007


Large number of US citizens demonstrated against the war in Iraq (and the possible war in Iran) during this October weekend. Massive turnout in Boston and San Fransisco, and also in Chicago, LA and DC people took to the streets.
The message was: NO more war in Iraq! NO to a war with Iran!