05-20-2018 01:57 AM
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
05-20-2018 06:59 AM
My advice would be to contact the authors.
Bob Schor
05-20-2018 05:17 PM - edited 05-20-2018 05:21 PM
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?
05-20-2018 05:30 PM
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.
05-21-2018 03:57 PM - edited 05-21-2018 03:57 PM
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...
05-28-2018 03:00 AM
@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...
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.
05-28-2018 10:37 PM - edited 05-29-2018 09:04 AM
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.
05-29-2018 03:35 AM - edited 05-29-2018 03:36 AM
@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...
05-29-2018 09:24 AM
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.)
05-29-2018 09:33 AM
Sheese where were you guys 6 years ago when I spent 10 minutes writing this to answer a question on encryption using LabVIEW? 😛