LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Encryption using Fast Fourier Transform

Greetings to the NI community

 

I am to transmit an encrypted text file and receive the decrypted text file using USRP 2932. I am a student beginner to the LabVIEW. I found a paper on the FFT encryption of a text file which can be found attached. I am struggling with its understanding as it does not contain copious documentation of the VI's. It is a humble request out there to kindly help me explain the Encryption and Decryption VI's. I am attaching the SC of the VI's also. I know it's a shot in the dark but i would really appreciate any help.

 

Thanks and regards

0 Kudos
Message 1 of 11
(4,721 Views)

My advice would be to contact the authors.

 

Bob Schor

0 Kudos
Message 2 of 11
(4,688 Views)

In general, I would not trust authors that can't even spell LabVIEW correctly. Some of the code shown on the attached picture is completely silly. Encrypting 8 bits into CDB or CSG seems very inefficient, same for encrypting plain text into formatted numerics spread over two files. There is no obvious encryption/decryption key, so it is basically security by obscurity

 

(Decryptor: Mostly useless sequence structure, That shift register in the rightmost loop serves no purpose, all you get is the string from the last iteration, etc. Why so much DBL and CDB if all you keep is 8 bits

Encryptor: Mostly useless sequence structure, all calculations to determine N should be blue. That coercion dot on the subVI worries me, etc.)

 

Do you have a generic need for encryption or do you really want to tackle some questionable old code using an obscure algorithm with no track record? 

0 Kudos
Message 3 of 11
(4,659 Views)

Those VI's call a sub VI. All the magic happens in there... Post those sub VI's if you want to know how they work.

 

Seems to me that PDF explains it all. But as it's written in typical academic lingo, you probably need a (specific) PhD to fully appreciate it.

0 Kudos
Message 4 of 11
(4,656 Views)

Well the simplest form of encryption you take a bit stream and XOR a repeating "key", the longer the key the stronger the encryption.

 

Decrypt is the reverse, XOR the key with the encrypted data stream and the output will be the original data.

 

Here is something I did a long time ago to encrypt and decrypt a text file, I am not sure how you would work the USRP into it...

 

enc-dec.png

========================
=== Engineer Ambiguously ===
========================
Message 5 of 11
(4,611 Views)

@RTSLVU wrote:

Well the simplest form of encryption you take a bit stream and XOR a repeating "key", the longer the key the stronger the encryption.

 

Decrypt is the reverse, XOR the key with the encrypted data stream and the output will be the original data.

 

Here is something I did a long time ago to encrypt and decrypt a text file, I am not sure how you would work the USRP into it...

 

enc-dec.png


That uninitialized shift register seems like a bug to me. It will give proper results, but every time the VI is run, a little more memory is used an not returned.

0 Kudos
Message 6 of 11
(4,564 Views)

wiebe@CARYA wrote:
That uninitialized shift register seems like a bug to me. It will give proper results, but every time the VI is run, a little more memory is used an not returned.

Exactly. In fact that loop should be a FOR loop (The total number of iterations can be fully determined form the sizes of the inputs before the loop starts!) and we could just autoindex into a 2D array at the right boundary because the reshape operation will accept that too, giving the same result.

Most likely it could be made even more efficient by XORing in place, section by section.

0 Kudos
Message 7 of 11
(4,551 Views)

@altenbach wrote:

wiebe@CARYA wrote:
That uninitialized shift register seems like a bug to me. It will give proper results, but every time the VI is run, a little more memory is used an not returned.

Exactly. In fact that loop should be a FOR loop (The total number of iterations can be fully determined form the sizes of the inputs before the loop starts!) and we could just autoindex into a 2D array at the right boundary because the reshape operation will accept that too, giving the same result.

Most likely it could be mode even more efficient by XORing in place, section by section.


I think the idea was that the array would grow if it's too small, and recycle the old array if it's big enough. That's a valid concept, and the shift register does the trick. Except the array also grows if it's big enough, and keeps doing that forever. So there's a leak.

 

Also, Key can't ever change, but still needs to be given each cycle.

 

Calculating and a for loop might indeed be easier on the mind...

 

I try to avoid while loops for algorithms like these. Things tend to be overlooked. For instance, what if Key is an empty string? You've got yourself an infinite CPU burner...

Message 8 of 11
(4,539 Views)

Yes, we need to protect from zero-length keys, but the math is especially simple (in=out) in that case 😄

 

Here's what I might do. The loop can even be parallelized, but I doubt it would make a big difference. (Same code for encryption and decryption.)

 

encryptdecrypt.png

Message 9 of 11
(4,522 Views)

Sheese where were you guys 6 years ago when I spent 10 minutes writing this to answer a question on encryption using LabVIEW? 😛

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 10 of 11
(4,518 Views)