Instead of 0 and 1, incomprehensible characters are displayed

[againtry]

@prog222
I've tidied up you code to get rid of the junk. Your code hasn't been materially changed and I suggest you concentrate on what I have done in the encode() function which provides the answer to what your are looking for. It should now be obvious to you what is going on and why.

BTW Technically LFSR as a key generator is rubbish - it was defeated years ago as a form of encryption. Worth knowing about but not much else for serious cryptography.

#include <bitset>
#include <iostream>

void generate_key(std::string& k)
{
    uint32_t state = 0b1111111111111111111111111111111;
    uint32_t start_state{ state };
    uint32_t period{ 0 };
    uint32_t bit { 0 };
    do
    {
        bit = ((state >> 31) ^ (state >> 30) ^ (state >> 29) ^ (state >> 25) ^ state);
        k[period] = bit;
        state = (state >> 1) | (bit << 31);
        
        std::cout << std::bitset<32>(state) << std::endl;
        period++;
        
    } while ((period != 15) && (start_state != state));
    
    std::cout << "  period: " << period << std::endl;
}

std::string encode(std::string d_str, std::string& k_str)
{
    std::string output = d_str;
    
    std::bitset<1> dbit{0}, kbit{0}, xorbit{0};
    
    std::cout << "*** xorbit: ";
    for(int i = 0; i < d_str.size(); ++i)
    {
        dbit = d_str[i] - '0';
        kbit = k_str[i] - '0';
        xorbit = dbit ^ kbit;
        std::cout << xorbit;
        
        output[i] = d_str[i] ^ k_str[i];
    }
    
    std::cout << '\n';
    return output;
}

int main()
{
    std::string key_str = " ";
    generate_key( key_str);
    
    
    std::string data_str = "1111";
    std::cout << "data_str: " << data_str << '\n';
    
    
    std::cout << " key_str: ";
    for(int i = 0; i < data_str.size(); ++i)
    {
        key_str[i] += '0';
        std::cout << std::bitset<1>( key_str[i] );
    }
    std::cout << '\n';
    
    
    std::string encoded = encode(data_str, key_str);
    std::string decoded = encode(encoded, key_str);
    
    
    std::cout << " encoded: " << encoded << '\n';
    std::cout << " decoded: " << decoded << '\n';
}

00111111111111111111111111111111
10011111111111111111111111111111
11001111111111111111111111111111
01100111111111111111111111111111
00110011111111111111111111111111
10011001111111111111111111111111
01001100111111111111111111111111
00100110011111111111111111111111
10010011001111111111111111111111
11001001100111111111111111111111
11100100110011111111111111111111
01110010011001111111111111111111
00111001001100111111111111111111
00011100100110011111111111111111
10001110010011001111111111111111
  period: 15
data_str: 1111
 key_str: 0110
*** xorbit: 1001
*** xorbit: 1111
 encoded: \303 \326\375
 decoded: 1111
Program ended with exit code: 0

[prog2222]

@againtry thanks!
I thing that question can be solved.

[againtry]

:)

[The Grey Wolf]

prog222, I'm going to leave you in the hands of againtry (good look with that). He seems to have some sort of issue with me and it is not fair to you to be pulling you in different directions all the time.


If you are interested, the Handbook of Applied Cryptography is available for free here.
https://cacr.uwaterloo.ca/hac/

Good luck.

________________________________________________________________
Edit The previous two posts hadn't shown up when I wrote this.

[prog2222]

@The Grey Wolf
Thanks!
It can help

[againtry]

The vulnerability of the LFSR key method is a technical problem vs a bruised ego problem.
The LFSR key is a deterministic pseudo-random key. Therein lies the problem. The periodicity factor is part of that ability for it to be easily exploited.
Further vulnerability presents itself if the key is shorter than the message.
Aside from that the usual vulnerability associated with transmitting the key exists, but that is not unique to LFSR - hence public key encryption which is designed to overcome that.
As a one time pad it's arguably OK, provided the key is secure. 2 or more uses and the ciphertexts may as well have been sent plain.

[The Grey Wolf]

againtry wrote:

The vulnerability of the LFSR key method is a technical problem vs a bruised ego problem.

It's got sweet FA to do with bruised egos and sweet FA to do with if I think LFSR is a good key generating method. The OP demonstrated a fundamental lake of understanding. I was simply using the code that the OP posted and the stated issues to try to get to the OPs difficulties.

[againtry]

Yes, I understated it, it's a technical problem vs a very bruised and fragile ego.

The simple facts are:
1. You were first off the cab in posting what I, and probably others, saw at the same time regarding type mismatches in @OP's code. A heroically insightful and admirably speedy effort by you at the keyboard to get a valuable comment recorded so @OP can get some comfort that posting here was not in vain.
2. Focussing on key generation appears to be your interest rather than the application of it which is @OP's issue as alternative code shows. encode() is the problem, not key_generation(), as can be seen.
3. The LFSR might also be a preference for not just one but many people but that doesn't detract from it's inherent vulnerability. It certainly was in the past until shown to be vulnerable to simple attack.
4. My code and and solution to @OP's problem is for all to see whether it's right, wrong or indifferent, or even a mouth-burst.
5. But, thank you for making me doubly sure that I am right. My solution addresses and solves the original problem, if @OP's post is any indication, and my comments on LFSR are technically correct, worthy of mention AFAICS and no cause for complaint, angst or delusional bizarre references from frankenstein and prometheus et al.

[The Grey Wolf]

Whatever.