Score:1

Crypto

Is it secure to use XOR to encrypt a 32bit number?

Ahmad Dehnavi

11/27/23, 1:00 PM

Let's say I have a 32-bit number and a primary secret key and want to encrypt it without increasing the size.

this is how I'm doing the encryption,

I create an HMAC hash using the primary key and current date as data
Then XOR input bytes with hash bytes a few times

for (let offset = 0; offset < hash.length - 4; offset++) {
    const key = hash.readUInt32BE(offset);
    input ^= key;
}

Is it secure? if it's not, is there any secure chipper algorithm to encrypt 32 (or fewer) bits of data without increasing the data size

I really appreciate any help you can provide.

253

1 + 0

Score:1

Crypto

Maarten Bodewes

11/27/23, 1:53 PM

In principle you are creating a key stream based on a secret key and a public, hopefully non-repeating piece of information: the date. This can be secure, it is how stream ciphers work after all.

However, that's the theory, let's look into the practical issues with your scheme:

Do you have a way to store or restore the current date? If you need to store it then you have increased the data size.
The date here acts as a nonce, otherwise the security is as low as for a many-time-pad.

As for 2: How do you know for sure that you do not repeat the date? Can you be 100% sure for the encryption method to be only called once with one particular date? I'm presuming that you are using a date format that cannot repeat by itself, but clock differences and such are still a problem.

The type of cipher that you may be looking for is called FPS, Format Preserving Encryption. It has a bit of a different security proposition as a stream cipher: it is secure except for the fact that it will create the same ciphertext for the same input.

However, it is possible to combine the ciphers with a so called "tweak" which may be public:

In addition to the formatted data for which the modes provide confidentiality, each mode also takes an additional input called the “tweak,” which is not necessarily secret. The tweak can be regarded as a changeable part of the key, because together they determine the encryption and decryption functions. Tweaks that vary can be especially important for implementations of FPE modes, because the number of possible values for the confidential data is often relatively small, as discussed in Appendix A and Appendix C.

Your "date" may be a perfect tweak, or at least component of a tweak, assuming that the date doesn't require additional storage (which would of course defeat the purpose of a FPS scheme). In principle an ever changing input that is common for each plaintext (like the current date) is not the best input for a tweak. A hash over a non-changing data element that is related to the plaintext would be better, like a user ID + column name, for instance.

One practical disadvantage of FPE is that it is often missing from mainstream crypto libraries. It also has had some breaks and near breaks of cryptographic security related to it, especially for small domains - so please remain vigilant and don't use just any FPE scheme or implementation.

+ 7

Ahmad Dehnavi

11/27/23, 2:12 PM

Thanks, Maarten Bodewes, I'm using this algorithm to create time-based passcode that only works on a specific date, the input itself is created based on some parameter including the day of the year, as the user has to enter this number manually on a device and there is blocking mechanism in case of incorrect attempts, also the device knows the date so I don't need to send the date itself.

Maarten Bodewes

11/27/23, 2:16 PM

Alright, but in that case I'd also include the user ID (or some other value that is specific for the device / transaction etc.), so the ciphertext is made user specific. Of course, if you lose such a value then decryption will become impossible, so some care needs to be taken. Anyway, the idea is to make the Tweak unique. You may need to use the (leftmost bytes of) a cryptographic hash to make it compatible with the cipher scheme used.

Ahmad Dehnavi

11/27/23, 2:16 PM

I use the date as hash function input because in addition to some primary secrets it is the only thing that is known by both sides, (the server that creates the passcode and the device that decrypts, validates, and saves the passcode), so with this assumption, do you think it is ok?

Maarten Bodewes

11/27/23, 2:17 PM

As long as the key / tweak is unique you won't be leaking information. Pretty please with sugar on top: use UTC and read out the time **once** and verify that it is the same on both sides before you use it.

Ahmad Dehnavi

11/27/23, 2:28 PM

Maarten Bodewes, first of all, I really appreciate you, for spending your time answering my questions, if I encrypt for example 20 different inputs using the same date, and if someone knows a few valid passcodes (output of this encryption) for that date and knows the encryption algorithm, is it possible to break the encryption, I mean in this case, is it possible for them to find the key or create new passcodes?

Maarten Bodewes

11/27/23, 2:51 PM

No, that should be secure when it comes to *confidentiality*. **However**, it seems like you are trying to design a One Time Password. That was not what your question was about (as you've only talked about ciphers, and ciphers by themselves just offer confidentiality). For *authenticity* / *integrity* 32 bit is not enough by itself; one could e.g. easily bruteforce 32 bit values over a network.

Ahmad Dehnavi

11/27/23, 3:04 PM

Yeah, it's a time-based passcode (having start and end times and a few more data that are encoded in it), we only validate passcodes on an offline device and because users have to enter the digits it can't be longer, and brute force is handled as a few incorrect attempts will block the keypad for a while, ... . so I think it should be fine. thanks again, Maarten :), have a nice day (or night maybe)

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Is it secure to use XOR to encrypt a 32bit number?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.