# Out of Tree Encryption block

**URL:** <https://www.ruby-forum.com/t/out-of-tree-encryption-block/230052>\
**Category:** GNU Radio\
**Created:** [May 28, 2014, 3:26pm UTC](https://www.ruby-forum.com/t/out-of-tree-encryption-block/230052 "2014-05-28T15:26:25Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\
**Post date:** [May 28, 2014, 3:26pm UTC](https://www.ruby-forum.com/t/out-of-tree-encryption-block/230052/1 "2014-05-28T15:26:25Z")

</div>

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](http://gnuradio.4.n7.nabble.com/Out-of-Tree-Encryption-block-tp48595.html)  
Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![dushyant.marathe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/5f8ce5/32.png) [@dushyant.marathe](https://www.ruby-forum.com/u/dushyant.marathe)\
**Post date:** [May 28, 2014, 10:46pm UTC](https://www.ruby-forum.com/t/out-of-tree-encryption-block/230052/2 "2014-05-28T22:46:52Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![dushyant.marathe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/5f8ce5/32.png) [@dushyant.marathe](https://www.ruby-forum.com/u/dushyant.marathe)\
**Post date:** [May 29, 2014, 10:35am UTC](https://www.ruby-forum.com/t/out-of-tree-encryption-block/230052/3 "2014-05-29T10:35:05Z")

</div>

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:

---

<div class="post-metadata">

**Author:** ![dushyant.marathe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/5f8ce5/32.png) [@dushyant.marathe](https://www.ruby-forum.com/u/dushyant.marathe)\
**Post date:** [May 29, 2014, 11:34am UTC](https://www.ruby-forum.com/t/out-of-tree-encryption-block/230052/4 "2014-05-29T11:34:15Z")

</div>

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 🙂

Greetings,  
Marcus