Xalky – Chat like a cockatoo!! With Peer-to-peer signing + Triad AES Revolving Keys!!


I have been working on a XOOPS 2.5 Module called Xalky; it is a chat program that is like an IRC Chat that free floating with room-to-room peer signing between websites so groups of users can chat between the free floating mesh of room chat!

I am writing this article to explain the triad AES Key system I will be using in this program to secure the peer exchange with a something known with expiry and on-contact historical stab and guess key for with the AES Encryption Algorithm ( aes.php | aes.js.php )  .

I started this application from another frame work many months ago while I was still suffering like I am now from a programming injury, RSI Agony! I have decided to change the framework of the ‘look’ and it is in an animated Modal that popup’s from the bottom of the screen.

The Code Stamp For this project is as follows:-

/**
 * Xalky - Code Stamp Example - cipher.labs.coop - XOOPS Chat Rooms
 *
 * You may not change or alter any portion of this comment or credits
 * of supporting developers from this source code or any supporting source code
 * which is considered copyrighted (c) material of the original comment or credit authors.
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 *
 * @copyright   Chronolabs Cooperative http://sourceforge.net/projects/chronolabs/
 * @license     GNU GPL 3 (http://labs.coop/briefs/legal/general-public-licence/13,3.html)
 * @author      Simon Antony Roberts <wishcraft@users.sourceforge.net>
 * @see		http://sourceforge.net/projects/xoops/
 * @see		http://sourceforge.net/projects/chronolabs/
 * @see		http://sourceforge.net/projects/chronolabsapi/
 * @see		http://labs.coop
 * @version     1.0.5
 * @since	1.0.1
 */

Revolving Key One – 128 Byte Blowfish Salt

The first aes blowfish salt ( aes.php | aes.js.php )   is the peer-to-peer signing, these expire + will do peer dial-back to resign around the expiry date to rewrite in both peering recording, for a key that is static for a period of time up to a random expiry time-stamp in the future.

There is 2 records for this one in the source website in the peer exchange and the remote peer exchange paralleled the database, this is between a source peer and a remote peer.

This all happens in the `xalky_blowfishing` table; and is done through the callback records in the `xalky_peers` table.

TABLE `xalky_blowfishing`

xalky/sql/mysql.sql

CREATE TABLE `xalky_blowfishing` (
  `salt-id` varchar(32) NOT NULL,
  `source-peer-id` varchar(32) NOT NULL DEFAULT '',
  `remote-peer-id` varchar(32) NOT NULL DEFAULT '',
  `source-salt` varchar(128) NOT NULL DEFAULT '',
  `remote-salt` varchar(128) NOT NULL DEFAULT '',
  `created` int(12) NOT NULL DEFAULT '0',
  `updated` int(12) NOT NULL DEFAULT '0',
  `expires` int(12) NOT NULL DEFAULT '0',
  `date-zone` varchar(64) NOT NULL DEFAULT 'Australia/Sydney',
  PRIMARY KEY (`salt-id`,`source-peer-id`,`remote-peer-id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Revolving Key Two – 128 Byte Blowfish Salt

The secondary aes blowfish salt ( aes.php | aes.js.php )   is the peering signing, these expire + will do peer dial-back to resign around the expiry date to rewrite in both peering recording, for a key that is static from the initial signing between room local and room remote to connect them with the /peer command we are going to build into the room control.

The only time these keys would rewrite is when the seeding changes; this is when you have the most local users, the channel program will elect you as the seeder. This is for load balancing!!

This happens with these 4 fields in the table below:-

  `local-aes` enum('yes','no') NOT NULL DEFAULT 'yes',
  `local-aes-salt` varchar(128) NOT NULL DEFAULT '',
  `remote-aes` enum('yes','no') NOT NULL DEFAULT 'yes',
  `remote-aes-salt` varchar(128) NOT NULL DEFAULT '',

There is 2 records for this one in the source website in the peer exchange and the remote peer exchange paralleled the database, this is between a source peer and a remote peer.

The four fields will update in the paralleled when the seeder changed this four fields – are peer group set based on the number of local users you have in the shared room-to-room; which remember other people could have multiple rooms peered on theirs which in one share with you they can have all that room in your room operating, private messaging direct etc.

When the following four fields change, it elects a need seeder in the group peering share relay (That is the four fields illustrated above get renegotiated:-

  `seeder-peer-id` varchar(32) NOT NULL DEFAULT '',
  `seeder-name` varchar(250) NOT NULL DEFAULT '',
  `seeder-uri` varchar(250) NOT NULL DEFAULT '',
  ...
  `room-seeder` enum('yes','no') NOT NULL DEFAULT 'no',

This all happens in the `xalky_peering` table; and is done through the callback records in the `xalky_peers` table.

TABLE `xalky_peering`

xalky/sql/mysql.sql

CREATE TABLE `xalky_peering` (
  `peering-id` varchar(32) NOT NULL,
  `local-room-id` varchar(32) NOT NULL DEFAULT '',
  `remote-room-id` varchar(32) NOT NULL DEFAULT '',
  `drop-link-pass` varchar(32) NOT NULL DEFAULT '',
  `local-owner-user-id` varchar(32) NOT NULL DEFAULT '',
  `remote-owner-user-id` varchar(32) NOT NULL DEFAULT '',
  `callback-peer-id` varchar(32) NOT NULL DEFAULT '',
  `callback-name` varchar(250) NOT NULL DEFAULT '',
  `callback-uri` varchar(250) NOT NULL DEFAULT '',
  `seeder-peer-id` varchar(32) NOT NULL DEFAULT '',
  `seeder-name` varchar(250) NOT NULL DEFAULT '',
  `seeder-uri` varchar(250) NOT NULL DEFAULT '',
  `local-users` bigint(20) unsigned NOT NULL DEFAULT '0',
  `remote-users` bigint(20) unsigned NOT NULL DEFAULT '0',
  `send-messages` bigint(20) unsigned NOT NULL DEFAULT '0',
  `recieved-messages` bigint(20) unsigned NOT NULL DEFAULT '0',
  `local-aes` enum('yes','no') NOT NULL DEFAULT 'yes',
  `local-aes-salt` varchar(128) NOT NULL DEFAULT '',
  `remote-aes` enum('yes','no') NOT NULL DEFAULT 'yes',
  `remote-aes-salt` varchar(128) NOT NULL DEFAULT '',
  `room-seeder` enum('yes','no') NOT NULL DEFAULT 'no',
  `room-save` enum('yes','no') NOT NULL DEFAULT 'yes',
  `remote-ping` float(22,16) NOT NULL DEFAULT '0.0000000000000000',
  `remote-down` enum('yes','no') NOT NULL DEFAULT 'yes',
  `started` int(12) NOT NULL,
  `last-message` int(12) NOT NULL,
  `last-ping` int(12) NOT NULL,
  `delay-ping` int(12) NOT NULL,
  `finished` int(12) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`peering-id`,`local-room-id`,`remote-room-id`,`remote-down`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Revolving Key Three – 128 Byte Header Salt

The secondary aes header salt ( aes.php | aes.js.php )   is the peering signing, these expire + but do no reassignment around the expiry which is the memory of the remote peering PHP Session with cURL Cookie set; see with this key it is passed to the source of the key from the header in a sequence of one of the one exchange in the last few hours; so the AES Cipher can try to unlock several packages based on the source data md5 checksum value decrypted which is passed in the header IP Packets.

The following headers are set with header() for cURL to discovery of on your site running xalky and XOOPS within xalky/preloads/core.php:-

xalky/preloads/core.php

// Sets Contextual Headers with Encryption Blowfish Keys for Discovery method
header('Xalky-URL-Site: '. XOOPS_URL);
header('Xalky-URL-Chat: '. XOOPS_URL . '/modules/xalky/');
header('Xalky-API-Callback: '. XOOPS_URL . '/modules/xalky/%s/callback.api');
header('Xalky-API-Data: '. XOOPS_URL . '/modules/xalky/data/callback.api');
header('Xalky-API-Profile: '. XOOPS_URL . '/modules/xalky/profile/callback.api');
header('Xalky-AES-Support: Yes');
header('Xalky-Peer-Sitename: '.$GLOBALS['xoopsConfig']['sitename']);
header('Xalky-Peer-Slogan: '.$GLOBALS['xoopsConfig']['slogan']);
header('Xalky-Peer-Email: '.$GLOBALS['xoopsConfig']['admin_email']);
header('Xalky-Peer-ID: '.($GLOBALS['xalkyPeerID'] = self::getPeerID()));
if (!is_array($_SESSION['xalkyOldIssuedSalt']))
	$_SESSION['xalkyOldIssuedSalt'] = array();
if (isset($_SESSION['xalkyIssuedSalt']))
	$_SESSION['xalkyOldIssuedSalt'][microtime(true)] = $_SESSION['xalkyIssuedSalt'];
header('Xalky-AES-Salt: '. ($_SESSION['xalkyIssuedSalt'] = $GLOBALS['xalkyIssuedSalt'] = self::getSalt(0,127,'')));

This key is to be used on exchange with a php session history with the caller; so in the last hour or so; when it is passed a AES Crypted ( aes.php | aes.js.php )  package this is used one of the Xalky-AES-Salt is used with sending to it source from the history of the last hour or so of contacts with the calling peer, or caller peer and is sent in all cURL Calls as a Header this sequence!~

Advertisements