Talk:Padding (cryptography)

Padding, whitening, IVs etc

Matt,

Padding is, in some sense, a higher genus of thing than both whitening and use of an IV. I was attempting to use the reference to both here as 1) an invitation to follow the link and learn something and 2) an attempt to make clear that -- at least conceptually -- both are additions (in principle arbitrary) to plaintexts or keys and so something of the same type, however different the details.

I don't see the generalisation. As I understand it, "padding" is an extension of the length of a message, such as "CAT" -> "CATXX". "Whitening" refers to scrambling the plaintext using a binary group operation with a subkey at either the initial or final round of an iterated block cipher. They are unrelated concepts, unless there's a different usage that I'm not aware of. Initialisation vectors are similarly unrelated conceptually, but I reckon its worth a "see also" since both are details that crop up when using block cipher modes.

Padding can be, and I recall that it was, used at both ends, and in the middle for that matter, of messages. In fact, Russian copulation was used as a sort of padding (though this is a stretch since no data is added) to move stereotyped ending/beginnings away from ends and begins. Not so important now when redundancy can be very effectively removed by routine use of compression. My memory of whitening differs, but... The article is looking more necessary, isn't it?

Ah, OK. (The definition I'm familiar with is noted in Schneier's Applied Cryptography, Section 15.6, if you have it to hand...) — Matt 23:43, 12 Apr 2004 (UTC)

A whitening article was, I suppose, in my future after some looking up of details I can't trust my memory to supply with fidelity. Sigh.

Go for it; I included a link from the Camellia article with that intention.

OK. But I will be taking a while with it, as I clearly can't just do it out of my head.

I suggest we reinstall mention of both whit and IV, with suitable notations as to the details of usage and such.

I think separate articles would be better.

Separate articles would indeed be good, and are obviously necessary; one exists (apparently) for IV, but I disagee that they shouldn't be mentioned here. If whitening has the meaning I thought it did. If it's your meaning, it obviously shouldn't be included here.

You might be interested to hear that I have finally had a penny drop. Seems like it took long enough. Many of the differences between you and I seem to be based in our attitude toward the reader. I keep always foremost in mind that the reader will be looking not only for facts but, being unfamiliar with the territory in many (most, nearly all, every?) case, and will benefit from explanation you deem surplus. Does this seem so to you as well? If so, do you have any suggestions as to how we might hit some middle ground on this dimension? ww 20:32, 12 Apr 2004 (UTC)

I agree that explanation that aids comprehension is good. However, some explanation can be extraneous and actually detract from the reader's understanding. I think we often disagree on what the reader is looking to find out, particularly in the encyclopedia vs textbook thing. — Matt 21:12, 12 Apr 2004 (UTC)

I guess the divergence is with 'extraneous', and with expository planning. I tie, or try to, things together to make easier the reader's road to understanding. More connections, more ways to see how things relate, more mental links, and perhaps a greater chance to understand them. Your style/inclination has fewer connections between concepts and forces the reader to do more conceptual contstruction.

I don't think the difference is textbook vs encyclopedia; even at my most extraneous, my work here is unsuited to a textbook. Having written one or two, I can speak with some authority on the inadequacy of my work here in re use in/part of textbooks.

We really should find a compromise on this, if this is the core of divergence, or you'll keep editing out my extraneous, and all will be uncomfortable. I need my extraneous to stay healthy! Seriously, at least for the occasional humourous aside, see Wetman's discussion of the place of humor here at his user page.

ww 22:44, 12 Apr 2004 (UTC)

Homer says, d'oh! example good!

C,

I'm afraid that I have to disagree with the deletion. It's true that there is a virtue in parsimony and cross linking to avoid unnecessary use of server space, there is also a virtue in writing article that will be read. Connections to things people may have heard about (Admiral Halsey, Admiral Nimitz, the return to the Philipines (never can remember, 2'l's?) are a kind of syntactic sugar which makes the medicine go down in a most (can't remember this Sound of Music lyric either). Wetware bit decay surely.

WP is not written for a specialist audience (where possible) but to inform, which means the vagaries of Average Reader are something its writers must take into account. It' probably not possible except by hwordy andwaving for such things as any flavor of string theory or most any currently researched math or ....

This article isn't one of those.

Comment?

ww 02:00, 26 September 2005 (UTC)

Moved this discussion to here from User_talk:Ciphergoth

The virtue in parsimony is that we can work on one really good account, rather than two disparate accounts that will inevitably be less good. It's possible we should write a better teaser for what is a really good story though. I love the sorts of pop-science bestsellers that add these sorts of asides to spice up this sort of information, but it's not the right tone for Wikipedia, and it doesn't work for the material about modern cryptography which is both the most relevant information to today and the section that needs the most work.

Also, of course, material about a battle in a faraway place sixty years ago will mean nothing to a lot of people and can even put them off. BTW, "A Spoonful of Sugar" is Mary Poppins :-) — ciphergoth 10:27, 26 September 2005 (UTC)

C,

Thanks for the Poppins ref. But, I couldn't disagree more with your position. This is an encyclopedia, and very ill behooves any writer to leave out things on their own estimate that a battle in a faraway place... will mean nothing... It's rather the most fundamental point of an encylopedia to have the facts, not for writers to prune them to meet some impression of relevance. Neither you nor I nor any writer here should ever do that.

That said, I agree that, in some ideal information transmission model (low noise, no loss, ...) parsimony has a certain elegance. WP is not a low noise environment, and everything written here is hostage to all (starting now and ending probably never). This is not an ideal Shannon information transmission channel. I suggest that parsimony is not the most sensible criterion for our writing under those conditions.

And finally a writer's point. Readers have predictable (more or less anyway) difficulty with what they read. They ranges from vocabulary (eg, have you read most any educational psychology stuff; tarting things up with lots of big words, ubiquitious passive voice, and obscuring phrase and sentence structure is an effective way to reduce any reader to uncomprehending rage) to the actual subject matter (eg, string theory) to writng style (eg no one would think Faulkner any sort of good choice for technical material) to too condensed (eg, a math text which consists entirely and only of theorems and their proofs) or too diffuse (eg, some 18th century histories, which go on and on and on and on) and so on. Since writing is an interaction between the author and the reader, part of that interaction should be to help the reader to master the material. In an account of Papal elections an explanation of the smoke color thing would by sensible (even if there's a separate article on smaoke color) and in this case, the padding idea thus far discussed both briefly and in the abstract is fleshed out by an example, a particular famous to boot.

Is my reasoning clearer and my disagreement with yours as well? ww 18:22, 26 September 2005 (UTC)

I still disagree. At this point I'd like to hear what someone else thinks. — ciphergoth 18:46, 26 September 2005 (UTC)

I fully agree with ciphergoth. Throwing in a smattering of humorous anecdotes might be appropriate in many forms of writing, but not in an encyclopedia article. — Matt Crypto 20:55, 26 September 2005 (UTC)

C & M, Enough ':'. Haven't had the count the bloody beasts in a while...

M, your agreement is not to a position C took, nor in opposition to my postion. It's a strawman. I am myself opposed to a smattering of humorous anecdote, and wouldn't defend them for an instant. That's not the point I'm making. I'd like to hear something more than I disagree from some other folks. I have to the effort of making my argument rationally at some length to invite exactly that response.

Futhermore, there is an interesting theoretical question here, which is right down a cryptiac's alley. Haven't gotten a response to that either. How about some dialogue? ww 09:43, 27 September 2005 (UTC)

With respect, Ww, my experience from the past is that we're unlikely to agree on a question like this, and I don't see much point in engaging in convoluted and fruitless debate over it. As I said above, I agree entirely with Ciphergoth's arguments, so you can address those if you want. — Matt Crypto 16:18, 27 September 2005 (UTC)

Matt, It may be that we will be unlikely to agree and so on. We will certainly not do so without addressing points in disagreement. As for characterizing such interchange as convoluted and fruitless, well if that's your expectation, I'm sorry to hear you characterize them so. ww 11:03, 29 September 2005 (UTC)

Sorry if it came across as harsh; what I meant was that, given my past experience, it would seem we disagree fundamentally about some things regarding the nature of encyclopedic writing. Since we've discussed similar things at length in the past without agreement, I don't see that situation changing. — Matt Crypto 16:12, 30 September 2005 (UTC)

Appended Sum

Not sure if this is the correct name for it, but it is very common in software implemenations because it provides many integrity checks and is easy to implement —Preceding unsigned comment added by RealWorldExperience (talk • contribs) 18:28, 20 May 2008 (UTC)

But it is not a cryptographic standard like all the other padding schemes in this article. It isn't a good proposal either, since it always leads to an additional plaintext block. Whether similar paddings are used somewhere else is not relevant. Your proposal still is original research and hence should not be added to a wikipedia article. 85.2.16.120 (talk) 22:22, 20 May 2008 (UTC)

section removed from article -- discuss here, please

This was removed from the article in toto for two reasons: poor writing style and poor citations. It also is the same material mentioned just above, I think. Should this be cleaned up and reinsetted or stay out even if cleaned up?

====Bijective Bit padding====

Padding that fails a valid padding oracle leads to attacks see the following for a more clear explanation [http://www.usenix.org/publications/library/proceedings/sec02/full_papers/black/black_html/index.html

Side-Channel Attacks on Symmetric Encryption Schemes: The Case for Authenticated Encryption]. One could access for more info on padding to avoid common weakness

Takes a little more time to compute but can allow for one less encrypted block of output data. This may be important if space is a concern or if one wishes to reduce the ability of an attacker to use an attack based on cipher text only. Granted, for most ciphers this is often not needed. However, the simple bijective bit padding would produce exactly the same output as described above but could require one less output block. When looking at this from the attacking point of view, depending on input, the plain text of the last block could well be in hex the "80 00 ... 00 00". This would give an attacker added information to establish a break. The chance of this being the last block with bijective bit padding is lower since often the trailing "80 00 ... 00 00 " would never need to be sent at all. The less information given to the attacker the harder it is to break. Another weakness of normal bit padding mentioned above is that the last block to be encrypted is never all zeros meaning that any key that leads to making the last block all zeros on decryption could be ignored right away.

The only change needed to the rules above occur when the input string is an exact multiple of bits needed for the blocks. In this case for bijective bit padding as mentioned here, you only drop the extra "80 00 ... 00 00" if the last data block was all zeros or a tail of all zeros followed by one or more data blocks of "80 00 ... 00 00" This would exactly match the the results for padding with non-bijective method mentioned above except that it would sometimes allow for one less block.

ww (talk) 03:33, 26 September 2008 (UTC)

ISO/IEC standard?

Is there a specific ISO/IEC standard that defines padding methods independently of other operations? ISO/IEC 9797-1 ... MACs includes some padding methods, but defines them in the context of MACs (although the padding methods are independent of the MAC algorithms, so the 9797 padding methods can be used for operations other than MACs). ISO/IEC 10116 Modes of operation ... explicitly states that padding is not within its scope. Mitch Ames (talk) 14:22, 7 April 2012 (UTC)

Withdrawn ISO10126

Can someone please point here, why ISO10126 was withdrawn? — Preceding unsigned comment added by 85.180.61.251 (talk) 17:46, 17 January 2013 (UTC)

security considerations of different byte padding methods

Are such comparisons out there, which padding might be more secure than other? --RokerHRO (talk) 21:57, 13 August 2013 (UTC)

cipher types versus modes of operation

The article says: "An example of streaming mode encryption is the counter mode of operation."

I'm not an expert on ciphers, but I believe this is incorrect. There are two high-level types of ciphers: stream ciphers (operating on a sequence of bits, bytes, or short blocks), and block ciphers (operating on larger pieces of input at once). It is probably ok to say that these types are converging, but it is not true that using these in different modes of operation changes their types. "CTR" mode is a way to use block ciphers, not a way to change stream ciphers into block ciphers.

Can someone with a good understanding of this please update the article?

   It's technically correct, but a poor example.
   A cipher in counter mode can operate on either a block or a bit - the only distinction being that the input determining the next state of the                 
   encryption algorithm is solely from a sequence of numbers (the counter), instead of using the output of the encryption algorithm.
   I guess I'll update it to refer to a synchronous stream cipher.
   [Schneier, Bruce - 'Applied Cryptography' 2nd ed. p206]

   Ok, I clearly don't know how to format stuff here. Punting that^ update, sorry.