4 ms·
Forgot to answer this: > One-time pads are impractical. You need a key that's as long as your message. Pre-shared. Need in a key as long as your message (pre-
by plugnburn 11y ago
Forgot to answer this:
> One-time pads are impractical. You need a key that's as long as your message. Pre-shared.
Need in a key as long as your message (pre-shared) doesn't mean that OTP is impractical.
Let's imagine a conversation between two users that exchange tweet-sized messages in Latin-1 encoding (i.e. each plain message weighs no more than 140 bytes).
Let's consider we've produced exactly 4 GiB of random key data and distributed it between the two users (on a pendrive or somehow else).
When the message is received, its encrypted length is the same as the raw length, so we just move the key pointer for the message length on each send and reception.
So how many 140-byte messages can be sent with 4 GiB of key data? Math.floor(4 * 1024 * 1024 * 1024 / 140) = 30678337.
So, 4 GiB of pre-shared key data allows us to send over thirty millions of tweet-sized messages for both sides. How in the world is this impractical? Especially at our days when a 16 GiB file is a norm.
And yes, pre-sharing these key data can involve a simple SSC, BSC etc. It might be hard for an attacker to figure out when to stop when he constantly gets a random garbage out of the same-looking random garbage.
- rnovak 11y ago> Let's consider we've produced exactly 4 GiB of random key data and distributed it between the two users if you have a method of securely distributing 4gb of key, why on earth wouldn't you use that to transmit the message itself? That's 100% impractical
- plugnburn 11y agoBecause that method doesn't imply the key distribution channel will be available 100% of the time. In fact, it implies the opposite: one-time transmission. For the next 4 GiB, it would be wiser to switch the channel. Between these two occasions, we have plenty of time.
- rnovak 11y agoIt doesn't matter. In order for OTP to work, you first have to invent secure communication. It puts the horse before the carriage. Oh, and now you have to maintain perfect secrecy/privacy of a 4gb file. Solved one problem (theoretically), and now you have a multitude of practical issues. So again, OTP is impractical.
- plugnburn 11y agoIt does matter. You can, for example, initially share the key data on a pinlocked pendrive. What would be really impractical is using this pendrive to transmit actual messages. Whether OTP is practical or not, entirely depends on real-world conditions. P.S. Tell all this to the OP, not me. I'm not building an OTP system.
- rnovak 11y agoYou understand that a secure pen-drive (which is what I think you're talking about by 'pinlocked') has a HSM (Hardware Security Module) with hardware implementations of standardized encryption algorithms, right? You literally just suggested using standardized encryption algorithms to protect your OTP key. Or you could...you know...just use standardized crypto across the board. OTP is by definition impractical. I'm sorry that you don't see that.
- plugnburn 11y ago> You literally just suggested using standardized encryption algorithms to protect your OTP key. I suggested using standardized (or non-standardized, but other than OTP) encryption algorithms for an initial key data distribution channel that completely differs from the main communication channel and exists for a relatively short period of time. That's my key point. > Or you could...you know...just use standardized crypto across the board. I'm not going to dive deep into the topic of why I consider "just using standardized crypto" unsafe and prefer rolling another custom end-to-end encryption layer on top of it. > OTP is by definition impractical. I'm sorry that you don't see that. I'm sorry that you can't see beyond the algorithms. We're far ahead of the time when OTP was the only active instrument (aside from straddling checkerboards and Enigmas). Modern crypto can be combined in such a way that every encryption scheme finds its natural place. I honestly don't see why OTP cannot have one.
- rnovak 11y ago> I'm not going to dive deep into the topic of why I consider "just using standardized crypto" unsafe and prefer rolling another custom end-to-end encryption layer on top of it. please, by all means, enlighten us. > I'm sorry that you can't see beyond the algorithms. Please keep in mind that you have no idea what my background is (or what experience I have), so don't assume that I "can't see beyond the algorithms".