Encryption using Fast Fourier Transform

[altenbach]

---

@BertMcMahan wrote:

---

@billko wrote:

---

---

Sorry I have trouble taking a person's opinion of LabVIEW seriously that calls nodes on the palette "blocks". Calling them "blocks" is ridiculous. VIs. Functions. Even primitives. Not "blocks".

---

I mean, it is called the "block diagram" 😉

---

If functions and subVIs were blocks, it would be called the "Blocks diagram". 😄

Here is one....

[Frozen]

---

wiebe@CARYA wrote:

You don't need the name; you can match the function from the palette by how it looks.

Granted, it does help to have 25 years of experience. 😁

It doesn't help that the appearance changes over versions and when function inputs or options change...

---

Well... you would hope the functions on the block diagram would match them in the pallet... as I review this idea again 🤐

[Andrey_Dmitriev]

---

@Frozen wrote:

---

wiebe@CARYA wrote:

You don't need the name; you can match the function from the palette by how it looks.

Granted, it does help to have 25 years of experience. 😁

It doesn't help that the appearance changes over versions and when function inputs or options change...

---

Well... you would hope the functions on the block diagram would match them in the pallet... as I review this idea again 🤐

---

You won’t believe it — I’ve been working with LabVIEW since v.6.1 and never ever noticed any visual differences like missing scissors on "delete...". Until now, I was sure they were the same. And usually I pay attention to single pixels; they matter... Well, maybe it was just a bit of subconscious anxiety, buried somewhere in the background of my mind... Now it’s really bothering me — I’m checking other primitives too, looking for possible differences. The world will never be the same for me again.

[wiebe@CARYA]

---

@VIEWfreak wrote:

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 think the root of this question, now flame war, is that what you're trying to do is quite ambitious.

I hope you hang in there, to give LabVIEW a change. It's easy and fast to do easy stuff but there is a learning curve for complex problems.

We are here to help...

[alexderjuengere]

---

wiebe@CARYA wrote:

---

@VIEWfreak wrote:

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 would start with the flow diagram 5.1 at page 37, 
"[...] characters from the file are extracted using the “Read from text file” function to encrypt.

After the extraction of the characters the “string to (byte) array” function is used to assign every available alphabets and
characters their respective ASCII codes."

that translates to 

string to byte array does convert the sytring A to the number 65 (which is it's ascii representation, see table 1.1 page 38 )

 "After the conversion of characters into ASCII codes .the series of data available needs to be converted into a parallel blocks
(of) data, each block containing 8 bits of data as the Fast Fourier Transform used for domain conversion is an algorithm
implemented for input of 8 bits"

ok, this would be way easier if this was a picture instead of text -I think we have an 1d array of data and want to reshape it to an 2d array

probably some rube goldberg? but wait...

there is some information missing - or rather "information not explicitally communicated" - e.g. "Then an “Array to Cluster” is used to give input to the FFT algorithm [...] you need to know, array to cluster doesn't work with 2d arrays, and furthermore, you need to specify the number of elements inside the cluster manually by rightclicking the array-to-cluster function, which default is 9 elements. that is easily overlooked...

I am pretty sure, this must be set from 9 to 8, inside the for loop "serial to parallel"- for loop containing array subset

doing an FFT in LabView is relatively easy, which is the next step - but wait - the FFT.vi does expect an array as input, not a cluster -  instead of FFT.vi, you are meant to code your own fft function, which is conveniently described in 5.4.3 Block Diagram for Designing A 8-Bit Fft [...] the 8-bit FFT butterfly diagram is implemented using Lab VIEW functions. Therefore “Bundle”, “Unbundle”,”Multiply”,“Add” and “Subtract” functions are used

....

@VIEWfreak , it's your turn 😉

[altenbach]

---

@alexderjuengere wrote:

---

that translates to 

---

Careful there! You need to disable "convert EOL", else the number of bytes can change. I would just read it as U8 array instead.

Example: I am reading a large tab delimited text file and here are the resulting array sizes (top to bottom)

12330 (wrong!)

12409

12409

[altenbach]

---

@alexderjuengere wrote:
I would start with the flow diagram 5.1 at page 37, 

---

Remember that this is an ancient thread and I already commented on the (in?)sanity of that entire paper 7 years ago, shifting the discussion into encryption in general. I would not even call it "encryption", but "obfuscation".

It is not clear how a USRP-2932 fits into all this, because it the data is via file IO.

[banksey255]

A quite old post that has resurfaced, and presumably the one that posted it is no longer interested, but here is my analysis of how the encryption and decryption VIs work in case others are interested in the paper.

Encryptor module VI

1. Read the file as text (as altenbach pointed out, the way they do this converts EOL characters, so there is the possibility they can never recover the original file contents after this process)
2. Using a FOR loop, iterate through 8 element blocks of the data that:
   1. Converts to a cluster of 8 elements
   2. Computes the FFT
   3. Scrambles the element order (if you look closely, they just reverse the order)
   4. Computes the inverse FFT (they make use of the fact that the inverse FFT is equal to the complex conjugate of the FFT of the complex conjugated FFT divided by 8 because there are 8 elements, which allows them to reuse their FFT code)
   5. Converts the 8 element cluster to an array
   6. Outputs the array from the FOR loop as an N x 8 array. Because of how they compute N, if the data doesn't have a length that is an integer multiple of 8, this will either add up to 4 zeros to the end or lose up to the last 4 elements.
3. Separate the resulting real (encrypted part 1) and imaginary (encrypted part 2) components. They write these parts as text to files, so there probably will be precision loss.

Decryptor module VI

This is just a reverse of the encryptor module.

1. Read in the real and imaginary encrypted components and combine to form a complex number
2. Using a FOR loop, iterate through the N rows of the array that are each 8 elements long:
   1. Converts to a cluster of 8 elements
   2. Computes the FFT
   3. Unscrambles the element order. Because their example of scrambling code just reverses the order, they simply just use it a second time because reversing a reverse gets back to the original.
   4. Computes the inverse FFT (they make use of the fact that the inverse FFT is equal to the complex conjugate of the FFT of the complex conjugated FFT divided by 8 because there are 8 elements, which allows them to reuse their FFT code)
   5. Converts the 8 element cluster to an array
   6. Outputs the array from the FOR loop as an N x 8 array
3. Because of numerical precision limitations throughout the process:
   1. Even though the result should be real, it may not be, so they just keep the real part
   2. Even though the result should contain only integers, it may not be exactly, so they round to the nearest integer
4. Convert the result to a string. They also write this to a file converting EOL characters again.

This final string will be equal to the original string read into LabVIEW if the original string had a length that was an integer multiple of 8, otherwise it will be up to 4 elements shorter or longer, as mentioned above in the encryptor module VI, with any additional elements equal to zero. Also, because their read and write text file functions both convert EOL characters, even if the decryptor module returns the exact string read into LabVIEW, the contents of the decrypted file may not match the original file.

[banksey255]

As a correction to my previous post, it will never be shorter, but rather their encryptor module VI, due to how the number of FOR loop iterations is computed and step 2.1, will add up to 8 zeros to the end of the data.