HEKTOR 128 - Voice Encryptor,
based on complex Time Domain Scrambling

The basic idea of this project is to provide some pretty high level of voice security by consequent application of rapid time domain scrambling in conjunction with dynamic frequency shifting. The resulting complex audio remains compatible to almost any voice communications channel, whether analog or digital.

Project overview | Implementation | Hardware | Firmware | Testing | Operation | Download | Links | Index

Pic 1a: Not just another analog voice scrambler...

Table 1: Features

Complex analog voice encryption, independent, autonomous and transparent hardware solution
Method(s): Time-domain-scrambling and
frequency variation overlay in the baseband
Telephony / voice (300...3300 Hz max.)
Internal Codec:
Deltamodulation, 96 kHz in average
Blocklength: 1,28 s + 40 ms synchro
128 symbols per block,
64 frequency variations per symbol
Symbol duration:
10 ms in average (speed variation +/- 50 %)
16-digits decimal number
(symmetrical session key)
1016 initial keys (53-bit binary key)
Rolling code scheme:
Transtable - change with every block,
Freqtable - change with every pass/transit
Synchronisation: 1500 Hz start synchro (1,3 s)
1650 Hz block synchro (40 ms)
1650 Hz end synchro (~ 1 s)

Codename: "HEKTOR"

Analogue techniques of voice scrambling usually do not require more bandwidth, than unencrypted speech, thus may be inserted into most narrowband voice channel, regardless of analog or digital transmission layer. On that score, analog encryption has strategic advantage over many all-digital or even IP-based voice crypto solutions. (The latter ones are often considered 'state of the art', but most voice crypto applications present high infrastructural requirements and suffer from potential and well-known vulnerabilities of PC- or mobile platforms. Worst of all: None of the commercial solutions is fully disclosed, therefore they are not trustworthy at all.)

Basic concept

It is the thesis of this project, that the audio signal of human speech gains significant cryptographic complexity by application of rapid time domain scrambling with:
The proposed hardware consists of an inexpensive AVR-microcontroller with extra SRAM and only few analog components around.

This constitutes for an autonomous, transparent, experimentation-friendly and inexpensive platform.

The proposed firmware (=programming) digitizes the analog waveforms, keeps exact timing, and, of course, performs that complex variant of time transposition ciphering with large blocks and comparably high chopping frequency.

This project is and will ever be open source.

Cryptographical strength

In the current configuration, HEKTOR is set up as a symmetrical cryptosystem whoose initial keys are decimals numbers of up to 16 digits. These symmetric keys are entered directly into a keypad on the device. No external smartcards nor other additional storage needed. Passwords or decimals are in fact some comparably human-friendly (memorable) sort of key. The user is enabled to keep all key-management tasks in a straightforward, transparent, conservative and conspirative manner...!

With 16 decimals we have access to 10^16 different starting conditions (10 quadrillions). This equals to a binary keyspace of "only" 53 bits. Yet, since cryptoanalysis on such a complex analog signal is not a trivial task and implies some additional complications for an attacker. We will discuss some of these aspects later on. Foreclosing and subjective statement of the author: the overall security of this variant of time domain scrambling is well above what is normally considered 'tactical security'.

TO-DOs: The system may be extended by some means of asymmetric key-agreement that could then replace manual key entry. Yet this is only 'an idea' so far. Me personally would not completely forego the option of using symmetric numerical keys - since it allows to use the encryptor with minimum channel requirements, i.e. without the need for an errorfree exchange of digital data prior to establishment of the semi-analog encrypted communications session. Indeed, the current minimalistic protocol, only consisting of analog waveforms and timing-synchros, has proven quite robust in several applications now.

Analog encryption properties

In this project, we use a block partition scheme of 128 positions. This provides for a very huge subset of applicable cryptographic keys (i.e. tables that ensure random distribution of the signal wavelets). The sheer number of possible keys will render any exhaustive (brute-force) key probing futile, but also the more sophisticated methods, dealing with signal-analysis and correlations, will be very time-consuming for most realistic scenarios.
All transposition tables have good pseudorandom characteristics and change with every block of speech; no transposition scheme will be identical to the previous one or any other transposition within the same session.

The system applies some additional frequency 'modulation' on the sampling frequency of speech digitizer. This results in a frequency spreading of the audio in addition to their random placement in the time domain. While all means of frequency-related manipulation will be cryptographically weak as a standalone method, they can provide additional security to a time-transposition scheme. Signal gets even more unintelligible and gains robustness against frequency selective channel fading. Speaker identification and signal-analytic attacks should be even more difficult because of its 'fuzzy' time pattern.

Besides, the naming "HEKTOR" is no far-fetched acronyme; it's actually the greek prefix "hekto" (which means "a hundred") with a fancy "R" attached, not only for artistic purposes but also to express the radical application of transposition with some quite rapid symbol rate of approximately 100 transpositions per second. (See Table 1 on top of this page for the other basic parameters.)

Known drawbacks:
Speaking very slowly is known to deteriorate the security of a system that uses time domain scrambling, for obvious reasons.
Also, any time transposition scheme depends strongly on a good synchronization method, since the receiver cannot decrypt some transmission without knowing exactly where the block of transposed speech begins (and, of course, which transposition table is to be applied). This will demand for a good medium-term timing accuracy on the communications channel. Still these requirements for frequency response and timing accuracy should be covered by international minimum standards for voice telephony. Problems could arise with very poor analog/short wave radio channels, and with digital channels that use rapid compression, like GSM and some VoIP-Codecs.

Modus operandi

All encrypted communication will start as an unencrypted P2P call using the regular telephone set. Then, both may power up their encryption devices, enter the secret session key and activate crypto mode.

Now both should change the telephone receiver with the headset of the encryptor.
This is because the encryption device will completely take over the line and safely disconnect the phone from network. Switching to a separate device for encrypted communication is a reasonable measure to separate crypto from normal hardware. The latter may be 'buggy', while crypto utilities may be further protected by physical means of locks, seals or even blasting caps... (You know, more phantasy is better than more technology in that business!)

Due to the double buffering (first in the transmitting device, minimum delay on the channel, last in the receiving device) and because there is always additional synchronisation signals needed, the overall signal delay will accumulate up to 2.6 seconds in the proposed system. Of course, this is definitely too long for a "full-duplex" quarrel, so we have to do it "half-duplex". Actually, operation principles are very similar to ordinary voice radio with PTT (push-to-talk) button.

This hardware version

This project was first published in the german magazine FUNKAMATEUR [10]. The original article suggested a set of two PCBs, one for the encryptor itself and one extra 'interface board' to provide a tailored interface to connect with different radios or telephones. Yet, there was not too much experimentation on this topic, and my personal activities got a little stuck with that...

However, a simple and proven method for connectivity with the plain old telephone system existed from the beginning, and so it has been integrated with the HEKTOR base circuit. This version is comparably compact and fits onto single PCB of only 75 x 100 mm. This hardware had then been named "HEKTOR-kompakt".

NOTE: Hardware and functionality of this project referred to as "HEKTOR-kompakt" and
"HEKTOR-128" are widely the same. In particular, the microcontroller's firmware is directly interchangeable between the two variants, since the Microcontroller's peripherals and port assignments have not been changed and thus are 100% identical. (I will do my very best to keep further firmware compatible to that hardware platform!)


Hektor Gerät 2 geöffnet Picture 1b:
(POTS only)

Technical implementation

With today's electronic components and microcontrollers, anybody could make a time domain scrambler that is capable of amazingly complex transposition schemes and underlying crypto.

The present hardware platform consists of a standard AVR-microcontroller, the ATmega8515 with added SRAM, and a programming that controls the entire flow of data, procures key computation, voice sampling and memory management etc.

Besides, the voice signal is not being digitized by means of some internal A/D converter of the AVR - as the ATmega8515 doesn't have one - but with its on-chip analog comparator, he is capable of doing some analog-digital-conversion by way of "deltamodulation". (In the course of further project development, it turned out, that this deltamodulation has been a very good choice in terms of simplicity/processing and spectral properties of reconstructed audio.)

Considering that we will in fact need at least 64 kbits of data rate with deltamodulation of 'telephony' quality, we can store about 4 seconds of speech in a simple 256 kbit RAM. Well, this is just the right dimension for some heavy time transposition scrambler!

A very pleasant feature of the ATmega8515 is the ability to directly address parallel SRAMs by its parallel 16-Bit-address- and 8-bit-databus. The 62256 is such an inexpensive and robust SRAM-chip. (Hint: If you still have some fast SRAMs of the 61256 series on stock, these could also be used with a simple adaptor-socket!)
As a further component for external memory access we only need one 74HC573 latch to perform address/data-multiplexing. That's all. All timing and signal sequencing stuff is will be 100% administered by the processor core of the ATmega8515.

Most of the additional analog components is quite uncritical and standard stuff needed for convenient signal coupling to the telephone network and connect to a headset.

Hey, why not inserting the voice encryptor into the handset-telephone-connection cord?

Yes, there are many dubious products for 'voice security', mainly from US backstreet companies, using exactly that stupid method of interfacing. Well, we ain't supposed to copy that. First of all: The handset of conventional phones has always been a popular location for "bugs", since an eavesdropper could easily access all audio in "plaintext"; circumventing all means of encryption that may be applied only on a later stage. Second: at least in Europe, the wiring between telephone appliance and handsets is not standardized at all. Even the impedance of speakers and microphones may be quite different. There's no doubt that one can build an adaptor that fits for a certain series of brand telephones, but that's no flexible solution at all.
Completely different situation on the network side: Regarding analog telephone terminals (local loop of a 'public switched telephone network', PSTN) technical parameters have been internationally standardized many years ago. At least this will apply to: range of voltages, loop current, ringer frequency, frequency response, dial tones etc. So we came to the conclusion, that the most universal, most compatible option for analog crypto-phone-interfacing would be to simply take over the telephone line with a compatible device and detach the conventional phone from loop current at the same time. This allows to hold the connection that's already been dialled and continue straightforward with the encrypted part.
Just to be honest, there is still one minor flaw associated with this method... you will need a completely different phone connector for almost any country in the world - just have a look at this horrifying overview on current telephone jacks in Europe: http://www.holzinger.cc/phone/telefonstecker.htm

What is the cost of this amazing device?

The cost of this project with all accessories may be easily held under 100 Euros.


Circuit documents: HEKTOR-kompakt Version 1.0

1. HEKTOR-kompakt v1.0 (left click to enlarge, right click to "save as")
HEKTOR-Kompakt Schaltplan
2. Components list HEKTOR-kompakt version V1.0
Version 'Kompaktversion'
for direct POTS connection
Version 1.00
05/2008 - rev. 05/2012
Julien Thomas, Kiel (Germany)

Resistors (all 1/4 W):

R1          100k
R2-R8       470      
R9-R12      330
R13, R14    1k0
R15, R16    22k
R17         220k
R18         470k
R19         22k
R20         100
R21         15k
R22         22k
R23-R27     10k      
R28         100
R29         47k
R30         100k
R31         470


C1-C5       100nF ceramic capacitor
C6          10nF ceramic
C7          100nF film (MKS)
C8          100pF ceramic
C9, C10     470nF film (MKS)
C11         1µF/10V electrolytic
C12         22nF ceramic
C13         22µF/10V electrolytic
C14         220nF film (MKS)
C15, C16    22p ceramic, NPO
C17         47µF/10V electrolytic
C18         47µF/25V electrolytic
C19         100nF film (MKS)
C20         1nF ceramic


VR1        7805 (1 A standard linear voltage regulator)
D1         1N4001
D2         1N4148
T1-T3      BC547C
T4         BC337-25
IC1        AVR AT90S8515-16 or ATMEGA8515-16 PDIP
IC2        74HC(T)573
IC3        SRAM 62256 - 80ns
IC4        CMOS 4053
LED1       LED red
LED2       LED yellow
LED3       LED green
LED4       LED green (all LEDs Standard or Low Current)


- IC-sockets IC1-IC4
- chrystal resonator 10 MHz (HC18)
- matrix keyboard 3x4
- X1-X5 connectors 2,54-mm
- 2x5p connector for X6 (ISP)
- 4 pcs of 2-pin-connectors for the external LEDs
- printed circuit board 75 x 100 mm
- audio transformer for telephony app. transfer ratio 1:1 ... 1:5
  DC-resistance of primary winding (directly connecting POTS)
  should be above 100 ohms!
  (e.g. Conrad NTE-1 515940, 515701)
- Re1 -  Relay 5V/6V DIL - 2x changeover, coil resistance > 90 Ohms,
  e.g.   Finder 30.22.9 6V,  Takamisawa RY05 W-K
- Modular (Western) Connector RJ11, 6 pole
  Set of RJ11-Connector / cable / POTS-connector

3. PCB HEKTOR-kompakt v1.0b, single-sided, 300dpi, 75 x 100 mm (right click for download)
Layout HEKTOR-kompakt Bestückungsplan


Circuit details: HEKTOR-kompakt Version 1.0


This circuit needs stabilized 5 volts being provided by the standard 7805 linear voltage regulator (VR1). The current consumption in ready state is below 60 mA. The main portion of this current is due to the LEDs and audio-amplifier. In encryption mode, there's an additional current of about 30mA for the line relay. The overall current consumption may be about 100mA while active encryption is running.
The 1-Amp-version of 7805 could handle these currents without extra heatsink, provided, that we do not supply more than approx. 9 volts of input voltage.

Cryptographic engine

The main actor is an AVR-microcontroller ATmega8515 (IC1). To describe its peripheral circuitry, we go clockwise around the chip - see circuit plan for further reference:

The lines PA0-PA7 are used as 8-bit address and data bus. In their function as address lines they go directly to the Latch IC2, and to read and write SRAM bytes, they are directly connected to the datalines D0-D7 of IC3.

The output line PE0 delivers some PTT-signal, with HIGH for transceiving mode or encryption, LOW for receiving mode or decryption.
The current that can be delivered by AVR internal port drivers is sufficient to drive the Rx/Tx-LED and some further logic inputs.
The output line PE1 in its function as ADDRESS Latch Enable (ALE) controls the address/data multiplexing by the latch IC2 (74HC573). The line PE2 is configuered as output, too. It supplies a logic signal for to change between transparency mode and active encryption mode. HIGH voltage level on PE2 corresponds to crypto-mode, LOW means transparent mode. Line interface needs this signal to energize line relay Re1 that manages instant switch-over between conventional telephone and crypto-device.

This port supplies further 8 address lines, from which however only 7 lines are in use. Together with PA0-PA7 the lines PC0-PC6 constitute for a 15-bits address bus to access the whole memory allocations of the 32-KB-SRAM IC3.

The microcontroller co-ordinates all write and read cycles on the SRAM directly by the control lines PD6 and PD7 (as /WR and /RD).
PD2 only drives the control LED2 to indicate a sync state or sync pulses.
PD3 is the input for sychronisation signal, that has been amplified and delimited by T1 which nearly provides square wave TTL-levels when synchro-tones are coming in via AUDIO-IN.
PD4 is configuered as an output and is driven more or less directly by the internal result of the comparator output, forming the delta-demodulator low-pass (with R22 and C9) that feeds back to PB3 which is the non-inverting input (AIN1) of the internal comparator. Reference value for the delta modulator is the audio input signal, made DC-free by C14 and with a constant offset (R15/R16) of about 2.5 volts (half supply voltage). It is connected with the inverting comparator input, PB2 (AIN0).
Last, the output PD5 provides the delta-output signal (delta bit stream) to feed some similarly dimensioned lowpass (R23, C10) with a  backend buffer, consisting of T2 and its peripheral parts. This signal is passed over the coupling capacitor C13 (47µF) for connection of telephone.

PB0,1,2 and PB4,5,6,7 are used for matrix-scanning of the attached 3x4-keypad. Further, as mentioned above, the lines PB2/PB3 are utilized as comparator inputs (AIN0/AIN1) on demand to digitize audio signals. Beyond that, PB5/PB6/PB7 may function as an ISP interface (MOSI/MISO/SCK) which enables flash reprogramming over the ATMEL-specified 10-pin ISP connector X6.

Telephone Line Interface

As long as the encryptor is not powered up or stays in "transparent" mode, the line pair a/b will be directly forwarded to the phone by the line relay (Re1) to a'/b'. Just when the encryptor switches into the active crypto mode, controller rises the line "active/transparent" (PE2) to HIGH-level and thus energizes the line relay, throws off the telephone and other devices, connects his audio transformer (Tr1) to the line. With an impedance of about 100 to 300 ohms and since the switching is done in less than 100 ms, an existing connection will be hold safely and taken over.
When the transformer has been switched onto the line, the encryptor is able to transmit and receive audio signals in both directions to and from the telephone system.
The signal switching is performed by the CMOS triple analog switch (IC4, type 4053). The signal of an elektret mike (e.g. that one in the headset) is preamplified by the factor of 10 by the amplifier stage consisting of T3 and some passive components around before it gets digitized by the controller.
In the parts list I have listed some audio transformers, that have been tested successfully in this application.

Note: Audio levels and transmision ratio of line transformers are not critical at all. All parameters, synch-frequency, delta-codec and last-but-not-least, the telephone network itself, will tolerate a wide range of signal levels and distortions.


Terminal connectors on HEKTOR-kompakt PCB

Unstabilized DC from 6 to 9 Volts, max. allowable current 250 mA.
Voltage should come from a well filtered power supply or batteries.
Connection for 3 colums / 4 rows matrix keypad.
Analogue POTS terminal.
Should be connected to the telephone system by means of a modem-cable (4 lines, a/b and a'/b').
Direct connectivity for electronic microphone (e.g. Headset).
Direct headphone connector, preferably higher impedance type for voice application, e.g. headphone of a PC-headset.
This is the ISP-connector in accordance with ATMEL-specs.
These are four 2-pin-connectors for direct connection of normal LEDs.



There's an elementary testing mode available. It can be activated by pressing the "#"-key directly after the device has been powered up or reset by hardware.
In this testing mode, the program will go directly into an infinite loop, running the interrupt routine with medium speed adjustment and continuously generating the blockstart-signal of about 1500 Hz.
The signal is generated out of the SRAM with constant reading rate to allow for easy monitoring of the memory access cycles. In this testing more, the signal direction is fixed to "receive/decrypt" mode, so the line relay will not switch on and the 1.5-kHz-tone will be forwarded directly to the headset, thus enabling a qualitative assessment of some basic functions: This tone should have a smooth and stable character with no vibrato audible (no hard rectangle, rather triangle-style, few distortions).

Signals to measure in this testing mode
If all that's o.k., we already proven that: the firmware has been flashed correctly into the chip and is running; The clock-source has been correctly setup and is running with the external 10-MHz-chrystal (otherwise the frequencies would be much lower); the audio driver and signal switching works correctly that far. Well done!

Testing encryption and decryption

Now we would surely like to test encryption and decryption and listen to how it sounds. For testing on a single unit with no second device at hand, you can simply record an encrypted transmission and later on playback this recorded message into the device for decryption. With an old dictaphone or poor cassette recorders it might go wrong because of speed variations (flutter).
With a good cassette-deck or any PC-soundcard, recording and playback of a HEKTOR-transmission should be no problem.
Recording levels are not critical at all (for the device...). Just observe that the soundcard can record continuously. This should be not problem on current platforms. Anyway it's reasonably good idea to terminate all competitive processes not needed at the time.

Recording an encrypted test-transmission: Forward the signal a/b (from X3-2 and X3-3) directly to LINE-IN of the soundcard or recorder. Polarity doesn't matter. Now start the encryptor with a simple key (how about * 0 # ...) and wait until the yellow "Sync"-LED lights up permanently. Start recording. Take the microphone, press the key "0" and say something eventful. Release the "0" button after some 10 to 30 seconds of speaking. Wait further 3 seconds for the block-end-synchro has been sent completely. Stop the recording.

Playback of the encrypted test-transmission: Connect the signal path a/b (from X3-2 and X3-3) to the speaker/headphone output of the soundcard. Don't forget to reset the device, and re-enter the same code as before. (Otherwise you may not even recognize your own voice.) Playback the recorded and crypted speech signal. It will only take a few moments (about two blocklengths), until the device has detected Start Sync (yellow LED flashes sync-wise) and you can listen to the decrypted speech on the headphones.

For a one-way-testing with the (outdated) basic-assembler-hybrid version, the ZIP in the FA-Download-Section offers some audio files. These have been downsampled to a bad telephone quality (8kbits). It is to prove that the decryption procedure will even synchronize under poor conditions. These examples are decryptable with the standard code of  * 0 # .
IMPORTANT NOTICE: Newer versions of the HEKTOR-FW may not be compatible to these audio-samples.



Table 2: Operational states of "HEKTOR-128 analogue voice encryptor, software version 1.x

STATUS Options
testing mode Switch on,
press #
continuous tone
Restart with *
starting tone
(three beeps)
key input Start with *,
Input max. 16 digits,
confirm with #
confirmation tones
for keypress
Press 0 to talk,
Restart with *,
Back to Standby with #
Restart with *
other station
Press and hold "0"
Restart with *
lights nothing


The method of block synchronisation has proven amazingly reliable. The leading synchronization signal of one blocklength (1500 Hz) is long enough even in spite of possible latencies caused by Vox/Squelch/Tx-relay - related stuff (radio equipment), and its frequency is clearly to be separated from the Block-Synchro and End-Synchro which both have 1650 Hz with 40ms resp. 2000ms of duration.
Within a transmission, the system should re-sync with every single block. Even if one or more block synchros might have been 'lost' (due to signal jamming, interference, packet-delays), the system completely recovers in many cases upon the next sync was correctly received. In the meantime, the receiver's device will be "running free" with the precision of its own clock frequency. This allows to overcome at least two or three blocks of missing syncs.
Even if one complete pass or the last blocks of a pass have become illegible due to disturbance and loss of synchronization, there is a good chance to continue without the need to restart and re-enter some session key in a kind of zero-knowledge protocol. The transmitting part won't notice severe channel disturbance at the moment. He will just finish his transmission, finally release the PTT-button and wait for a reply. His device will regularly perform a number of table transpositions to reach the next "milestone", which is the next index of absolute table transpositions divisible by 128 without fraction. The receiving part would notice that something was going wrong. He may then wait until his device has detected the End-Synchro of its counterpart. If this was not the case, he may break the current pass by pressing the key "#". Anyway, this device will calculate the next milestone, et voila - both devices are again up-to-state. Note, that this method does not require any further exchange of key-related indexes or other additional and possibly compromising information!

Key agreement

For a symmetric cryptosystem, of course the old problem of the key agreement persists. We surely need a safe communication channel to exchange the numeric keys or some kind of key-generation rules.
Well, with internet and email, this shouldn't be real problem anymore. What about PGP or some good (!) stegano-tool? Being lazy, further keys may be exchanged directly via encrypted voice communications then.

Key management

Maybe some people are not willing to keep some plain 16-digits-numbers in their head. Maybe it's sufficient to just generate new session keys by simply combining some 8-digits secret key plus actual date - like this:

Secret key:   12345678
Date:         20080601
Session key:  *1234567820080601#

Hardware Security

A crypto-hardware that already works with memorable keys, should consequently "forget" all key-related information in the moment it is switched off. No permanent storage of keys in the EEPROM of the controller or external smart cards.
Such hardware may be used by everyone safely, without leaving sensible information in the device after it has been reset or detached from the power supply. The same applies, if the machine should get "lost" (stolen).



Historic programming (BASCOM/ASSEMBLER)
The first firmware for HEKTOR has been prepared and compiled under the GUI of BASCOM-AVR. Even that time, all the time-critical routines (deltamodulation, transposition cipher generator) was already written in pure assembler language, administered by some rather uncritical skeleton of BASIC code. Thanks to the high percentage of machinecode, this hybrid program could smoothly compile even with the demo version of BASCOM-AVR which is free of charge but has that sticky limitation to 2 Kilobytes of code.
This firmware is still available from the website of a german magazine [10], along with circuit documentation and 2-parted PCB-layouts for the HEKTOR-device in its first published version.

Future versions - pure assembler!
HEKTOR-firmware has been revisited only a few times in the last years, and in fact no major changes have been necessary; but there were always those annoying restrictions in conjunction with the BASCOM environment and its 'versionitis'. So it was only consequential to finally write the whole thing in pure assembler, which is undoubtedly the real deal for more demanding microcontroller apps.
Finally, i found the time to completely revisit, re-think and rewrite the whole stuff in Assembler with original version as a blueprint, but leaving not a single BASCOM-artifact now.
This should be our new standard of HEKTOR-128 in terms of stability and cryptographic strength, since it performs the original and well tested transposition scheme of 128-symbols-per-block with the original frequency-variation layout, yet with some improvements in terms of voice and synchro quality could be achieved (see source code or readme.txt).
Since this version is even 99% compatible to the initial version of HEKTOR, the spectrograms below still give good impression from the encrypted signal's spectral properties.
You can download the fully revisited HEKTOR documents from my server on the location mentioned below [12].

Flashing the ATmega
There are precompiled binaries and hex files available for direct programming of the AVR. Simply use AVROSP, TwinAVR or whatever tool you prefer, to bring the firmware into the ATmega8515. Please note, that on delivery, the fusebits of a new AVR are normally set to use internal RC-oscillator as the clock source. These bits must be altered to make the AVR use external 10-MHz-crystal for clock generation.
I recommend the following fusebit settings (Ext/High/Low): FF / D9 / EC
Screenshot below illustrates the respective fusebit settings for TwinAVR as an example:

Fusebits ATmega8515 Hektor



Spektrogramm weibliche unverschlüsselte Sprache

Spectrogram* 1:

Female speech, unmodified,
5 seconds.

*) This and the following transformation were generated with spectrogram [6].

Spectrogram 2:

Female speech, HEKTOR-128-
about 5 seconds,
3 blocks

The bright lines observed before and after the transmission are start (~1500 Hz) resp. stopp (~1650 Hz) synchronisation carriers.
Those bright points in a distance of 1.3 seconds are the Block Synchros.



A transparent, diy and open-source device for secured speech communication over analog telephone systems or voice radio has been suggested. The proposed system makes intensive use of time transposition ("time domain scrambling"), which is an analog encryption method that may be applied on the analog layer of almost every voice channel.

The project is and should ever be open source. The author does not state, that the presented software and hardware will be an ultimative platform for analog voice encryption. In fact, it is just a problem-oriented suggestion. If someone feels encouraged to submit a better approach, then he or she should publish this alternative solution under similar conditions.

PCBs or kits may be delivered by the author, but only by the piece and strictly on a P2P-basis.




[1]    Legal provisions (Germany) :

[2]    Tipps von Bernd Zimmermann zum Thema "Internetsicherheit":

[3]    Another poor scrambling device, yet professionally priced...:

[4]    Some interesting hardware device for time domain scrambling (Fa. Selectone, USA):

[5]    About Deltamodulation (in german):

[6]    Audio-Analyser "Spectrogram" from R.S.Horne (Shareware):
        Older but cute version of Spectrogram (Freeware), works fine for W9x- and W2k:

[7]   German Version of this article

[8]    - broken link -

[9]    Essay "Psychology of voice" written by a certain 'Max Power'
        With many interesting crossreferences: http://hireme.geek.nz/phychology-of-voice_research-paper.pdf

[10]   Thomas, J.: "Hektor 128 - Sprachverschlüsseler nach Transpositionsverfahren",
        FUNKAMATEUR 57 (2008), Issues 4/2008 and 5/2008
        Download HEKTOR documentation & software - Keyword "Hektor":

[11]  NVA-Technology, ciphering devices and military scramblers (armed forces of former GDR, late 80s ):

[12]  Download current HEKTOR 128 package



Revision: 07/2008, 03/2009, 06/2012, 10/2012, 12/2013