Talk:Padding (cryptography)

message: 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)
replies: text: 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)
thread_title:  Appended Sum 

message: 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)
thread_title: section removed from article -- discuss here, please

message: 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)
thread_title:  ISO/IEC standard? 

message: 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)
thread_title:  Withdrawn ISO10126 

message: Are such comparisons out there, which padding might be more secure than other? --RokerHRO (talk) 21:57, 13 August 2013 (UTC)
thread_title:  security considerations of different byte padding methods