Oceania CW Traffic Net

Tuesday     0630 Z      7.028 MHz

This is an efficient, streamlined traffic-handling net.
Request that stations check-in only if they have traffic to pass or
hear while others are checking-in that there is traffic waiting for them.

No QRUs please

Here's an opportunity to make some serious use of your CW skills
through innovation, challenges, encryption and plain-text QTCs.
Between weekly nets, calling frequencies are 3.528 and 7.028 MHz,
or prearrange traffic exchanges by text or email.

Experimentation with diverse encryption methods is welcome,
so long as a URL pointing to a decryption facility is made available within your QTC.
 

Contributors to this net or those passing interesting traffic off-net are invited
to submit their completed Wireless Telegram  forms for upload
 to their own history page by emailing a JPG file conforming with size specifications to:
 
Telegrams/Enigmagrams  may be typed or legibly handwritten.
 

Example of a Telegram image with specification
600  X 500 pixels and a file size between 30 and 40 kB

Explanation of the Telegram shown above:   

PREAMBLE   is in the well-known standard Telegram format. 

MESSAGE    text has been encrypted using  software written by Stephen ZL1ANY to imitate the historic One Time Pad  (OTP).  The message text ends with a URL pointing to the file needed to decrypt the text, specifically dd.py.   This message field is where your imagination can be creative, have free rein to  produce challenging messages with which keen-others may engage and reply.

The FROM and BACK OFFICE fields are in the standard format using local time.

Some Considerations Regarding Encrypted CW Traffic.

 German Enigma traffic was sent only once.   No repeats or repeat requests were permitted due to the known potential for compromising security of the key.   Nonetheless,  Enigma worked successfully because random letter-for-letter substitution meant that a single letter error during transit resulted in only a single-letter error in decryption.   The context was usually sufficient  to permit an acceptable understanding,  bearing in mind that all numbers were spelled out.   
 

However, when a dictionary-based encryption system is used,   not only is there a limitation on the vocabulary,  the range of which the sender will not normally know,  but a single letter error will inevitably result in an entire word error,  possibly making gibberish of the message.  

Repeats are a therefore necessity for dictionary-based encryption systems.  Repeats are not a threat to the key,  and indeed contemporary OTP traffic is repeated over and over by ‘number’ stations.   One-for-one random letter substitution is used and integers may be included,  so there's no need for numbers to be spelled out so long as the dictionary includes them.

In our case where the dictionary-based PYTHON OTP is deployed,  we use the procedural alert     . ??    to separate the first and second instances of the message text,  then a standard  =  at the end of the second instance.

A complex word-by-word check-sum could be used but it takes a considerable time to manually verify, while a simple check sum is inadequate for proving letter accuracy and cannot point to which letter or letters is incorrect.   Therefore,  if the current PYTHON OTP is be deployed, the message text must be repeated at least once, despite nearly doubling the transmission time. 

Longer transmissions are not such an important factor in 21st Century amateur radio,  considering  ...   You're not bobbing about in the Atlantic in a surfaced Unterseeboot ...  and there are no keen WRNS Wrens in a wooden hut at Portland Bill eagerly trying to DF you either!

How to configure M3 and M4 Enigmagrams

Traffic History Index

Printable Telegram Form,  single A5   JPG

Printable Telegram Form,  two A5 on A4   PDF

Instructions for decrypting PYTHON OTP messages on Windows OS

Promoter of RandomGram

Original Proposal for OCWTN

Return to website index