User talk:Ruptor

From Wikipedia, the free encyclopedia

[edit] Talk History

Some people enjoy seeing their own posts on other users' Talk pages and re-reading them over and over again. Unfortunately for them, I prefer keeping my Talk page clean only showing the talks in progress on it.

If anyone finds reading outdated conversations to be an exciting way to spend their time, they are welcome to dig those up in the page history. I will keep maintaining my Talk page clean and up to date. If it's against Wikipedia rules, I insist that those rules are changed and everyone is assigned moderator privileges for their own user pages to be able to clean up their own Talk pages and their own user pages from any nonsense posted on them by unwelcome visitors.

— Ruptor 16:33, 3 October 2005 (UTC)

You're certainly free to pursue whatever cleanup strategy you like on your talk page (although, as ciphergoth pointed out, there's a culture of doing things a certain way, and some strategies will be interpreted in certain ways). I'd encourage you to read the Civility and No personal attacks policies, though. Comments such as "nonsense posted by unwelcome visitors" are unnecessarily antagonistic. Wikipedia is a place where people inevitably have to work together on things. Because of this, we need to afford each other a basic level of courtesy and respect. — Matt Crypto 16:53, 3 October 2005 (UTC)

[edit] Initialisation Vector

(Hi Ruptor, I know this is old, but I wasn't sure if you saw my response, so I just thought I would copy-and-paste it. Feel free to delete this "discussion".)

Hello, Michael! Thanks for taking time to contribute to the IV page. I just wanted to discuss your correction. I'm sure you'd agree that the recepient does need to know the IV to be able to decrypt the message. It was just probably worded incorrectly. The recepient doesn't necessarily need to receive the IV when it can be simply calculated or measured - the IV can be current time for instance, if it's properly synchronised. —Ruptor 16:40, 18 October 2005 (UTC)

Hi Ruptor,

Yes, I agree it was just a combination of ambiguous wording and my own ignorance. I realized this soon after, agonized over my change, and nearly reverted it. I'm glad, though, that it prompted you to add to the page, because I think your explanations really help.

However, I do think there is a key point about an IV that may be worthy of explanation in the Wikipedia article. There are really two ways to think about, or describe, what an IV is. (NB: I don't have much experience with stream ciphers, so this pertains to block ciphers only. Does a similar dichotomy exist with stream ciphers?)

The first view, the "IV as initial input" view, is what is described in your article. The IV is a block of data that is used to initiailize the feedback register. Here, it is obvious that the receiver needs to know the IV, since an encryption algorithm in feedback mode requires this input to operate correctly.

The other view, the "IV as salt" view, is that the IV is simply some random data that is included at the beginning of the plaintext, so that when encrypted (in feedback mode), the resulting ciphertext is unique. In this case, the feedback register is initialized with zeroes. Here, the receiver does not need to know the IV beforehand -- instead, the IV (as salt) is what the receiver sees as the first block after decrypting.

It seems clear that these two views are equivalent; the "IV as input" is merely the encrypted "IV as salt." (Note: If "IV as salt" doesn't really exist -- that is, if the distinction between "IV" and "salt" is clear to everyone, then either I am dense or the texts that I have read are poorly written, or both.)

I can understand why "IV as input" is the normal view, though, since it gives an implementor freedom to calculate the IV as they choose, and you nicely describe various ways that it can be computed. This freedom allows you to avoid, in some cases, the overhead of sending an extra block of encrypted data.

However, perhaps that is also the freedom to hang oneself? Schneir stresses in Applied Cryptography that the IV (as initial input) is not secret. So it seems to me that "IV as salt" has a minor advantage, in that the IV (as salt) is always encrypted with the private key. Therefore, even if an implementor chooses to unwisely attach semantics to the IV (i.e. it really should be secret), it is at least not available to an attacker in plaintext. Granted, since the feedback register is zeroed when encrypting the salt, the IV itself is exposed to the same attacks as ECB mode. With "IV as input," you can achieve the same protection as "IV as salt" by encrypting (in ECB mode) the IV. But I wonder how many people are actually doing that? It didn't even occur to me until just now.

Michael Birk 23:27, 28 October 2005 (UTC)

Hey, Michael! Thanks for your feedback. I'm not sure if encrypting IVs achieves much, but their general position is to be known to both parties and to ensure that two streams are always encrypted differently even if the same key is used. It's done primarily to save time on re-keying. I'm not sure if you've noticed it, but all the encryption modes of 'block' ciphers that require IVs are all modes of operation that transform block ciphers into 'stream' ciphers. If you dig in it long enough, you'll see that the IVs are specific for stream ciphers (or block ciphers turned into stream ciphers with one of the block chaining modes of operation). — Ruptor 16:26, 16 October 2006 (UTC)

[edit] Be Cool

I agree with the WP:RPA guidelines and I keep my talk page clean by simply removing everything that I consider to be a personal attack or libel. — Ruptor 16:38, 17 October 2006 (UTC)