Out of Tree Encryption block

GNU Radio
1

I want to simulate a voice transmission system in GNURadio Companion
(GRC).

My system configuration is as follows:

TRANSMITTER : Wav file source → encoder → encryption → modulator
→
RF

RECEIVER : speaker/Wav file sink ← decoder ← decryption ←
demodulator
← RF

I have simulated the above configuration in Ubuntu 12.04 machine but
without
encryption/decryption blocks.

If you can point me to an existing OoTM of digital encryption, it would
be
nice.

Thanks and Regards,
Dushyant

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Out-of-Tree-Encryption-block-tp48595.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

Hi Dushyant,

A side note:
I’m going to go assume that with “encoder” and “decoder” you mean
Channel Coding.
You must do channel coding after encryption, otherwise you won’t get
decryptable bits
as soon as you don’t have infinite SNR. This is not optional, because
with proper
encryption a single flipped bit will damage your signal in several
places.
This thread reminds me of
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-04/msg00277.html
so there might a solution to your problem there; Ralph has posted some
interesting insights
back then.

Usually, you’ll want to have something that applies something like a
block cipher on packetized data.
Although I’m not aware of any existing Modules that do this, using
stream tagged blocks, and the
gr-digital header demux infrastructure, you should be able to packetize
your data and encrypt the payload
en bloc, for example using AES.

Greetings,
Marcus

3

Hi all,

The system configuration proposed by Dushyant with encryption after
channel coding can work in case of stream ciphers. This is how it is
done in GSM. But encryption GSM is a very bad example of application of
cryptography. Channel coding will add some known relations between
information bits and it will be source weaknesses in the overall
cryptosystem.

Best Regards,
Piotr K.

W dniu 28.05.2014 22:45, Marcus M. pisze:

4

Hi Piotr, hi Dushyant,

GSM
of course, that’s true; but it’s, as you said, widely agreed upon that
this is security-wise a bad design choice; and it drastically complicate
design of such a transmission system (because you can’t check
transmission correctness before decryption).
With stream ciphers, a wrong symbol in the ciphered text stays but a
wrong symbol in the plaintext; for GSM designers this was important,
because the neither had the hardware that would have made handsets
capable of decoding big blocks of data, nor was channel coding that
effective in the beginning; I agree, for things like audio applications,
where occasional post-FEC bit errors are totally ok, a stream cipher
will be the right choice. Maybe my mind was a little centered on
packeted data transmission, where you’d want your channel coding to
detect all bit errors, and the system to retransmit that package (iff
these can’t be corrected). With an effective zero-bitrate per receive
packet, doing a stream cipher has no functional advantage.

So: You got me there :slight_smile:

Greetings,
Marcus