constant length string from random length string

I have a BigInteger class. It kérős the number in a string and for RSA encryption i need these numbers to be constant length without someone to see where each one starts. I was thinking of with << put the bits of the characters into ints and if no more chars left put a 0 byte there but it's not safe enough.

What do you think how to store the encrypted text in the file?
Why do you need your numbers to be of constant lengths?
Could you not encrypt the strings from your BigInteger class directly, as byte-chunks?
You could put a space or something between your number representations of the strings.
I'd like not to have any separator characters because it's far harder if its all in 1 line without any help of separators.
I was thinking of pushing 1 char to an int and keep doing it until its full, after that a 2nd int and so on. So the int would start as 0 and fill it up with bitwise operators (<<) with the bits of the chars. But to decrypt it it would be a bit painful tho if you find the null character you know the string has ended there and the next number will be the next string encoded. But this would still need separators as well, just its harder to see the logic in it than if I were to encrypt Apple az for example
100 123 123 300 -67 because now it basically looks like it.


P.s.: I need it to join to a lab at my university so I can show I'm interested in learning.

You can see the full code here:
https://github.com/Davoda1/vallo.david/tree/EncryptionENG_v1
Last edited on
I'm looking at time about your code :-)

You want to implement the en/decryption engine at yourself, without the use of widely proven tools like gnupg?

That's a very bad idea!

Consider that for secure proven encryption tools many security experts have to look at the code.
Also, there exists a plenty of attacks, not only at the encrypted files but also at the running programs.
Almost all, when not all programs, at where a programmer tried to program an en/decryption alone without the help of security experts, got broken.

I'm not a security expert, but I found still a huge failure of your core method Source::EncryptXOR:
Never ever use at XOR an encryption Key more than one! You need a key-pad which is at least such long as your plaintext and needs to hold randomly generated values,

I recommend you, using for your encryption proven standard tools like gnupg.
Yes I could use something which is made and I have no way to see/understand the source code, but how would I learn from that?
I learn by going to university and by making problems to solve for myself. As someone who barely started programming it's unlikely that I'll solve the greatest problems in IT or to be better than the experts who are working in this field for many years now.

I don't say you are wrong because you are not. All I'm looking for is to make a working if not flawless program that I made (at least in part because these are all well known things I didn't come up with anything new but in reality it cannot be expected from me I think).

back to the "problem" i was thinking of something like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
        string encrypt_key = "3";
	string decrypt_key = "587";
	string main_key = "391";

	string text = "apple";
	string new_text = "";

	vector<unsigned int> code_vec;
	int code_vec_index = 0;
	for (int i = 0; i < text.length(); i++)
	{
		string temp = EncryptRSA(text[i], encrypt_key, main_key);
		for (int k = 0; k < temp.length(); k++)
		{
			code_vec.push_back(0);
			if (k < temp.length())
			{
				code_vec[code_vec_index] += temp[k] << 040;
				++k;
			}
			if (k < temp.length())
			{
				code_vec[code_vec_index] += temp[k] << 030;
				++k;
			}
			if (k < temp.length())
			{
				code_vec[code_vec_index] += temp[k] << 020;
				++k;
			}
			if (k < temp.length())
			{
				code_vec[code_vec_index] += temp[k] << 010;
				++k;
			}
			++code_vec_index;
		}
	}
	
	for (int i = 0; i < code_vec.size(); i++)
	{
		string temp = "";
		if ((char)(code_vec[i] >> 040) != '\0')
			temp += code_vec[i] >> 040;
		if ((char)(code_vec[i] >> 030) != '\0')
			temp += code_vec[i] >> 030;
		if ((char)(code_vec[i] >> 020) != '\0')
			temp += code_vec[i] >> 020;
		if ((char)(code_vec[i] >> 010) != '\0')
			temp += code_vec[i] >> 010;
		new_text += DecryptRSA(temp, decrypt_key, main_key);
	}


So my idea is that if I store the chars in an unsigned int it will be constant length and i wont need separator characters.
Sorry, I cannot follow your problem, maybe because it's hard for me, thinking me
into other's minds. So I cannot see, why you don't want to pad your strings
with separator chars. Sorry for that, I apologize me.

AFAIK, the encryption process is such:

* The plaintext will get XOR-encrypted with a random one-time pad.
* For getting this on-time pad, we use a random number generator.
* This RNG needs a seed, which could be a hash of the plaintext.
* This seed needs to get encrypted with RSA and its public key.


Decryption would process like:

* The seed will get encrypted by RSA and private key.
* Then, this seed will feed the RNG so we rebuild the one-time pad.
* This one-time pad gets XORed with the encrypted text, resulting in plaintext.

1
2
3
4
5
6
7
8
9
10
11
// encryption:
seed := hash( plaintext )
one_time_pad := RNG( seed )  // Need to be longer than plaintext.
encrypted_text := plaintext XOR one_time_pad
encryptd_seed := RSA_encrypt( public_key, seed )


// decryption
seed := RSA_encrypt( private_key, encrypted_seed )
one_time_pad := rng( seed )
plaintext := encrypted_text XOR on_time_pad


The plain-text is now XOR-encrypted, and you don't need to bother about
number sizes.

If we choose the on-time-pad larger than our plaintext, others could not
even more comparing of file sizes.
I think I understand it, if not fully yet, but i'll try to implement it and use it. Thank you for your answer and if all goes well I will be able to achive a working program.
Feel free to ask, if still something ins unclear to you.
Topic archived. No new replies allowed.