Re: [Discuss-gnuradio] Out of Tree Encryption block

[Marcus Müller]

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

On 29.05.2014 10:33, Perper wrote:
> 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 Krysik
> 
> W dniu 28.05.2014 22:45, Marcus Müller pisze:
>> 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
>>
>>
>> On 28.05.2014 15:25, dushyant.marathe wrote:
>>> 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.
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>