HEKTOR 128 - Voice encryptor,
based on (very) complex time domain scrambling
The basic idea of this project is to achieve
some pretty high level of voice security just by intensive use of time
domain scrambling in combination with a frequency variation scheme.
These are so-called analogue techniques, that do not alter the
required bandwidth, thus can be inserted to almost any voice channel,
whether analog or digital.
Project overview |
Implementation |
Hardware |
Software |
Testing |
Operation |
Spectrograms |
Index
 Pic 1a: Yet another analog voice
scrambler...
Table 1: Features HEKTOR-Firmware V1.0 |
|
Codename: "HEKTOR"
It is the thesis of this project, that "time domain scrambling" will effectively compensate most redundancy in the human voice signal, when it is operated with long blocks and fine partition and a key generation scheme that produces good transposition tables of higher entropy changing for every transposition block.By this, the resulting analog signal should have build up enough cryptographical complexity to provide strong tactical security, even inspite of a serious attacker's signal- and crypto-analytical capabilities.
Since analogue techniques of voice veiling/scrambling usually do not require more bandwidth than unencrypted speech, they could be retrofit to most narrowband voice media, whether analog or digital. On that score, analog encryption has clear strategic advantages over most of those all-digital or even IP-based voice crypto solutions (e.g. "VoIP-Sec", "ZFone", etc.). They always produce higher infrastructural requirements; for special hardware/software, for a stable internet-connection or at least some guaranteed bandwidth over ISDN or UMTS; the known vulnerabilities of PC-based networking applications still remain; and worst of all, there's still some crap of commercial stuff that's not fully documented, so it's basically "security by obscurity" - just out of the question!
The proposed hardware consists of a standard AVR-microcontroller with some decent RAM-extension and only a few analog components around. This constitutes for an autonomous, transparent, experimention-friendly and inexpensive platform.
The proposed software for the microcontroller calculates transposition ciphers, digitizes the voice waveform, keeps exact timing in sync, and, of course, it performes this complex variant of time transposition ciphering with large blocks and a very high "chopping" frequency. All is open sourcecode, of course!
Key management
In the current configuration, HEKTOR is setup as a classic symmetrical cryptosystem whoose initial keys are decimal numbers of up to 16 digits.Keys are entered directly into a keypad located on the device. No smartcards nor other external media stuff. These decimal numbers should be still memorable - and this allows for the users to keep all key-management duties in a transparent, conservative, conspirative and most paranoid manner...!
With 16 decimal places we have nearly 10^16 different starting conditions (10 quadrillions) of possible keys for this cryptosystem. In binary notation this would be about 53 bits of keyspace. While the attack on such a complex analog encryption will always bind some significant computational capacity for signalanalysis, this keyspace seems sufficient for more than just tactical security.
Cryptographical strength
In this project, we even set up 128 positions for the
block partition. This will actually provide a very huge
subset of applicable cryptographic keys (i.e. tables that ensure
most random-like mixing of the signal wavelets). The
amount of applicable keys should render any approach of exhaustive
(brute-force) attacking futile by any means. It is further supposed
that other conceivable attacking strategies (based on signal-analytical
or phonetic approach) were too expensive and time-consuming for most
scenarios.Of course, the transposition table changes with every block. Of course, the key generation scheme was designed for good pseudorandom characteristics, and, of course we have not yet implemented any backdoors :-)
Additionally some frequency variation is applied in the proposed system. Admittedly, this would not even be much stronger than "frequency inversion" as a standalone method - but this is not the point. In combination with a time transposition cipher, we will benefit from the frequency variation's ability to "blur" the remaining frequency components that could have passed through the time transposition. This will surely make any phonetic approach of signalanalysis even harder. As a positive side effect of the frequency variation component, the spread audio spectrum gains more robustness against in-channel-disturbance.
Besides, the naming "HEKTOR" is no far-fetched acronyme; it's just 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 parameters.)
Drawbacks: That time transposition system represents some unusually high requirements regarding the medium-term timing accuracy on the communications channel. On the other hand, these requirements for frequency response and timing accuracy are still in the range of ITU-standards (let's hope, these standards will not be further levelled down in the future). And there has been lots of considerations and testing to find an idiot-proof synchronisation method. There may be further problems arising with very poor analog channels and digital channels that use rapid compression, like GSM, and likely some VoIP-Codecs.
Application
All encrypted communication starts as an unencrypted call using the regular telephone set. After consultation, both participants can power up their encryptors to enter the respective session key. Without muttering. In the next step, both parties agree to go "confidential mode" and activate their encryptor devices.Now both participants must change to the microphone and the headphones of the encryptor device instead of the telephone's receiver.
This is because the encryptor will completely take over the line and fully disconnect the phone. Changing to a completely different device for encrypted communication is always recommended. It allows to make a clear separation between the crypto-device and the normal hardware that is normally used for public communication and that is deemed unsafe, as is could be "buggy".
For the encryption equipment, technical manipulations may be prevented more strictly, e.g. keeping this equipment locked away, equipping it with blasting caps (More phantasy, better than more technology!).
Due to the intermediate storage of speech (once in the transceiving device, once in the receiving device) and because there is additional synchronisation needed, the signal delay accumulates up to 2.6 seconds in the proposed system. Of course, this is slightly too much for "full-duplex" communication; but it seems still practicable in half-duplex. This is why the system has been generally designed only for half-duplex operation, with regard to its compatibility with normal voice radio applications, too.
This hardware version
The project has been first time published in [10], while the mentioned article suggested some two-piece structure for the encryptor, one motherboard with a standardised contact terminal for the connection of different interface circuitry (for telephone systems, different radios etc.). Well , this "modular" approach was intended to facilitate experimentation with custom-made interfacing circuits to several radios. Unfortunately, there is still no universal HEKTOR-Radio-Interface available, and my personal activities got a little stuck with that...However, a simple and reliable circuit for coupling to some telephone line, the HEKTOR LINE INTERFACE, already exists. Now I have recently conceived the HEKTOR KOMPAKTVERSION with integrated line interface. This version is limited to telephone applications, but everything fits on only one PCB of only 75 x 100 mm now.
All functions of this "HEKTOR-Kompaktversion" are identical to the dyadic variant of HEKTOR-motherboard and HEKTOR-LINE interface. In particular, the current software/firmware is (and should be further on), still the same for both versions.
Up
 |
Picture 1b: HEKTOR-kompakt (POTS-only) |
Technical implementation
With today's electronic components, anybody could make a time domain
scrambling device that can do some amazingly complex
transposition
schemes and calculate very good symmetric ciphers.The present hardware platform consists of an AVR-microcontroller, the ATmega8515 with added SRAM memory, and a programme that does the entire flow control, procures key computation, voice sampling and storage.
Besides, the voice signal is not being digitized by means of some internal A/D converter of the AVR, just because - the ATMega8515 doesn't have one! But with his on-chip analog-comparator, he is in fact capable of doing some analog-digital-conversion due to the principles of "deltamodulation". (In the course of further project development, it turned out, that this deltamodulation has been a very good choice, not only because of its simplicity, but also because of some other favourable characteristics regarding signal quality and spectral properties.)
If we consider, that, for telephony purposes, one needs a delta-samplingrate of at least 64 kilobits, with this bitrate we could even store about 4 seconds of speech in a simple 256k-RAM. This is the right dimension for this kind of application.
A very pleasant feature of the ATmega8515 (among other AVRs) is his ability to almost directly address parallel SRAM-circuits with his parallel 16-Bit-addressbus and 8-bit-databus. The 62256 is such an inexpensive and robust SRAM-chip. (Hint: If you have some fast 61256 SRAMs on stock, these would also be fine with an adaptor-socket.)
As a further component, there's only one 74HC573 latch register needed for address/data-multiplexing. That's all. All timing and signal sequencing stuff is being administered to 100% by the processor core of the mighty ATmega8515. With this support, even ...say, moderate... programmers (like me) are able to easily address and utilize the vaste address room of 32 KB (or even 64 KB).
Most analog components are needed for convenient signal coupling to the telephone network and to some headset. The coupling between voice encryptor and telephone system is done by means of an audio transformer that is switched directly into the line current, while the ordinary telephone is simultaneously disconnected. (Basically this is the same way, analog modems or some answering machines take over the line.)
Why not inserting the voice encryptor into the handset-telephone-connection cord?
Well, this would not be a good idea from my point of view! First of all, the handset of a conventional telephone has always been some popular location for "bugs", because an eavesdropper would easily bypass any further encryption and will already get all spoken contents of a phone call served on a plate - in plaintext. Second point is, it ain't that simple to insert the encrytion device between telephone and handset, just because the interconnection between receiver and telephone is not standardized!!! Even the impedances of speakers and microphones are not necessarily uniform, so it would be lots of hassle to build a matchbox or some adaptor for the insertion of an analog encryptor in this place.
On the other hand, the electrical parameters of POTS line terminals are quite similar in every corner of the world; regarding loop current, ringer frequency and current, overall frequency response, dial tones. This is why we came to the conclusion, that the most universal, most compatible option for analog phone-crypto-coupling would be to simply occupy the line and throw the conventional telephone off.
However, in Central Europe you will most likely need a different cable/plug for any european country. Very strange. Just have a look at this horrifying overview on current telephone jacks: http://www.holzinger.cc/phone/telefonstecker.htm
Cost: The cost of this project with all accessories may be easily held under 100 Euros.
Up
Circuit documents: HEKTOR-kompakt Version 1.0
Circuit details: HEKTOR-kompakt Version 1.0
General
This circuit needs stabilized 5 Volts ("TTL") to be delivered by 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 1A-type of 7805 can still handle this without extra heatsink necessary, provided, that we do not supply more than 9V of input voltage.
Crypto Machine
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:PORT A
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.
PORT E
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. This signal is needed by the telephone line interface to automatically energize the line-relay Re1 that manages the instant switch-over between conventional telephone and crypto-devide.
PORT C
This port supplies further 8 address lines, from which however only 7 are used. 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.
PORT D
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 comfiguered as an output line. In conjunction with R22 and C9 is builds a low-pass for the delta-feedback-loop for the AVR-internal comparator circuit with PB3 as the non-inverting input (AIN1). Reference value for the delta modulator is the audio input signal, that is made DC-free by C14 and loaded with a constant voltage offset by R15/R16 over C14 onto 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.
PORT B
PB0,1,2 and PB4,5,6 are used for matrix-scanning of the attached 3x4-keypad. Further, as mentioned above, the lines PB2/PB3 are also used as comparator inputs (AIN0/AIN1) for the delta-ADC. Beyond that, PB5/PB6/PB7 can still be used in their function as an ISP interface (MOSI/MISO/SCK) to enable flash reprogramming of the µC over the ATMEL-specified 10-pin ISP connector X6.
Telephone Line Interface
As long as the encryptor is not powered up or it remains in "transparent" mode, the line pair a/b remains untouched and will be forwarded by the line relay Re1 to a'/b' and thus forwarded to the telephone. Just when the encryptor switches into the active crypto mode, the controller rises its control line "active/transparent" (PE2) to HIGH-level. This will drive the transistor T4 to energize the Re1. Now the LINE relay tightens, cuts off the telephone line path and puts his own audio transducer (Tr1) on the line. By its internal impedance of about 100 to 300 ohms it will hold up the current loop and keep the connection.NOTE: The higher impedance side should be on the side of the telephone network. Switching time is less than 0.1 s, which is normally too fast for losing the connection. With the transformer on the line, the device can now safely r transmit and receive audio signals to and from the telephone system.
A CMOS triple analog switch (IC4, type 4053) is doing all the switching of signal directions from the controller to the transformer and to headphone and microphone as well. The Mic signal of an elektret cap (e.g. in the headset) has to be preamplified by the factor of 10, this is done by the simple amplifier stage consisting of T3.
In the parts list some audio transformers are indicated that have alredy been successfully tested in this application.
Note: Audio levels and transformers transmision ratio aren't that critical. The synchronisation scheme will work in a wide range of signal levels. Both, the delta modulation and the codecs normally used in analog/digital conversion used in telephone networks permit greater tolerances. Too high levels are always limited.
Up
Terminal connectors on HEKTOR-kompakt PCB
| X1 |
Unstabilized DC from 6 to 9 Volts,
max. allowable current 250 mA. Voltage should come from a well filtered power supply or batteries. |
| X2 |
Connection for 3 colums / 4 rows
matrix keypad. |
| X3 |
Analogue POTS terminal. Should be connected to the telephone system by means of a modem-cable (4 lines, a/b and a'/b'). |
| X4 |
Direct connectivity for electronic
microphone (e.g. Headset). |
| X5 |
Direct headphone connector, preferably higher impedance type for voice application, e.g. headphone of a PC-headset. |
| X6 |
This is the ISP-connector in accordance with ATMEL-specs. |
| LED 1-4 |
These are four 2-pin-connectors for direct connection of normal LEDs. |
Up
Testing
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 1.5 kHz.
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).
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 1.5 kHz.
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
- Scope or frequency counter on pin 15 of the µC (this is PD5, the deltamodulation-out pin): in testing mode, there should be square wave of 50:50% duty cycle with TTL-levels at a frequency of 1510 Hz
- Unloaded Audio-OUT (after C13) should provide the amplified and smoothened audiosignal with triangle-waveform and a level of about 2Vpp
- On the pins 16/17 of the µC (PD6/PD7) some clocking/controlling signals with sharp pulses will occur. These identify the access on the external SRAM which recurrs in a frequency of 12080 Hz auf. (Remark: All frequencies refer to the current program version 1.0b.)
Actually testing the encryption- and decryption functionalities
Now we would surely like to test encryption and decryption and just listen to how it sounds. There's no second device needed for that test. All you need is a means of recording and playback to store some selfmade encryted transmission. With an old dictaphone or a poor cassette recorder it might go wrong because of instable speed (flutter).
With a good cassette-deck or any PC-soundcard, record and playback of a HEKTOR-transmission should work without a problem.
Also level conditions concerning the audio signal are not very critical. Yet it is of highest importance that the soundcard can record continuously without timing problems. At a PC we should close all other windows and terminate competitive processes.
Recording encrypted test-transmission: Forward the signal a/b (from X3-2 and X3-3) directly on a LINE-IN of the soundcard or given recorder. Polarity is unimportant. Now start the encryptor with a simple key (how about * 0 # ...) and wait until the yellow "Sync"-LED lights up permanently. Start the recording. Now put on the headset, press the key "0" and say something eventful. Release the "0" / "PTT" button after some seconds of 10 to 30 seconds of speaking. Wait some seconds for the block-end-synchro to be sent completely. Stop the recording.
Playback encrypted test-transmission: Now connect the signal path a/b (from X3-2 and X3-3) to the speaker/headphone output of the soundcard. Before playback you must reset the encryptor and reenter the same code as before. (Otherwise you will not even recognize your own voice.) Now put on the headset, start playback from the PC/other audiodevice and listen!
For a one-way-testing, the ZIP in the FA-Download-Section offers some audio files, that should be compatible with the current software (and perhaps with following versions). These were intentionally to a compareably bad telephone quality (only 8k-sampkes). It should be demonstrated, that the decryption procedure will even synchronize under pretty poor conditions. These examples are decryptable with the standard code of * 0 # .
Up
Operation
Table 2: Operational states of "HEKTOR-128 analogue voice
encryptor, software version 1.x
| STATUS | Options |
LED1 Trans |
LED2 Sync |
LED3 Rx |
LED4 Tx |
Headphone, speaker |
| testing mode | Switch
on, press # |
lights |
off |
lights |
off |
continuous tone |
| transparent
(passive) |
Restart
with * |
lights |
off |
lights |
off |
starting
tone (three beeps) |
| key input | Start
with *, Input max. 16 digits, confirm with # |
lights |
off |
lights |
off |
confirmation
tones for keypress |
| Ready, Standby |
Press 0
to talk, Restart with *, |
off |
lights |
lights |
off |
nothing |
| Receive
(decrypt) |
Back to
Standby with # Restart with * |
off |
flashes |
lights |
off |
other
station |
| Transmit
(encrypt) |
Press and
hold "0" Restart with * |
off |
flashes |
off |
lights | nothing |
Synchronisation
The method of block synchronisation has proven amazingly reliable. The system resynchs with every new block. But even if one or more block synchros were "loosen" by signal jamming or other interference, the system will recover in most cases when the next sync returns. In the meantime, the receiver's device is "running free" with the precision of its own clock generator, which allows to overcome at least two or three blocks of disturbed signal.Even if one complete transit has become illegible, there is no need to give up and restart, since both devices will start the next transit with one common table. (See the well commented sourcecode on how the trick is done.)
Just to add, this method of synchronisation and this kind of key generation (all devices use the same transposition table at the same time), likely allows more than just two parties for encrypted voice communication. Yet, it hasn't been comprehensively tested now, but it should also work in a telephone conference or a QSO round. To avoid collision, it may be a good idea to strictly determine some sequencing rules on which participant is allowed to transmit at a time.
Key agreement
Since it concerns a classical symmetrical cryptosystem, of course the old problem of the key agreement emerges. For this we surely need a safe communication way at least once to exchange the keys or to negotiate some kind of key-generation rule.Well, if we use internet and email, this shouldn't be real problem anymore. How about PGP or some good (!) stegano-tool? Being lazy, all further keys may be exchanged directly via encrypted voice communication 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).
Up
Firmware
SoftwareThe whole program has been prepared and compiled under the comfortable GUI of BASCOM AVR. The HEKTOR-firmware mainly consists of assembler routines, that are administered by some uncritical BASIC-structures. This has been the only way to implement that highspeed delta-interrupt and some really fast transposition key calculation. It is also owed to the high portion of machine code, that this program can be compiled with the demo version of Bascom AVR which is limited to 2 KB of programme code :-)
The source code is well commented, so it should be easy to understand the programming en detail.
Download
The stable version is available in the download section of [10]. Firmware is identical for the "classic" HEKTOR-version of 2 PCBs and the Kompaktversion suggested in here.
Flash programming
Of course there are precompiled binaries available for direct flashing. To program the AVR with AVR-OSP, AVRprog or TwinAVR, binary or Hex files are provided. 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 modified anyway to use the external chrystal. I however recommend to set the fusebits at first, because this would be the most critical moment.
Fusebit-pitfallsPicture to the right shows the fusebits in the representation of TwinAVR, as they must be set to configure the AVR to use external 10-MHz chrystal for clock generation. As a difference to the basic state of the chip, the CLKSEL0 is now set, which however means under TwinAVR, the checkmark has to be clicked away. Additionally CLKSEL2 and CLKSEL3 must be unset to activate external chrystal - this means, these fields must be checked now. In particular, one should refrain from the funny idea of only setting CLKSEL0 without clearing CLKSEL2 and CLKSEL3 simultaneously - as this will leave the AVR without any clock source - and in this state it wouldn't even respond to serial ISP/SPI anymore. (But that's not so serious: The chip is not broken. It will respond again, if we connect some external clocksource of e.g. 1 MHz to the pin XTAL1.)
Up
Spectrograms
 |
Illustrative Spectrogram* 1: Female speech, unmodified, 5 seconds. *) This and the following transformation were generated with the software spectrogram [6]. |
 |
Illustrative Spectrogram 2: Female speech, HEKTOR-128- encrypted, about 5 seconds, 3 blocks The lines before and after the transmission are the pure start (~1500 Hz) and stopp (~1625 Hz) synchronisation carriers. The bursts for block synchronization appear as bright points in a distance of 1.3 seconds. |
Up
Remarks
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") as an analog encryption technology that is easily to be applied on many different voice channels.
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, at least "open source"!
PCBs, kits or even ready-made devices may be delivered by the author, but only by the piece and strictly on a P2P-basis.
Up
Links
[1] Legal provisions (Germany) :
http://www.jusdata.info/de/materialien/tkgeheimnis-datenschutz.html[2] Tipps von Bernd Zimmermann zum Thema "Internetsicherheit":
http://www.www-kurs.de/lausch.htm
[3] Another poor scrambling device, yet professionally priced...:
http://www.pimall.com/nais/miser.html
[4] Some interesting hardware device for time domain scrambling (Fa. Selectone, USA):
http://www.com-spec.com/selectone/manual/600-0501.pdf
[5] About Deltamodulation (in german):
http://www.beis.de/Elektronik/DeltaSigma/DeltaSigma_D.html
[6] Audio-Analyser "Spectrogram" from R.S.Horne (Shareware):
http://www.visualizationsoftware.com/gram.html
Older but cute version of Spectrogram (Freeware), works fine for W9x- and W2k:
http://spot.fho-emden.de/ftp/elektron/gram50.zip
[7] German Version of this article
[8] Scientific article about some
aspects of voice recognition (german):
http://www.neurowissenschaft.ch/oldNeuro/Lehre/SS07/nkogspr/spectral-temporal.pdf
[9] Essay "Psychology of voice" written by a certain 'Max Power'
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":
www.funkamateur.de/downloads
http://www.neurowissenschaft.ch/oldNeuro/Lehre/SS07/nkogspr/spectral-temporal.pdf
[9] Essay "Psychology of voice" written by a certain 'Max Power'
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":
www.funkamateur.de/downloads
[11] NVA-Technology, ciphering devices and military scramblers (armed forces of former GDR, late 80s ):
http://freenet-homepage.de/SASundChiffrierdienst/t217.html
Up
Index
25.08.2008