3

We are using the below cipher

AES/ECB/NOPADDING

But I am little confused because modes like ECB need the input to be padded according to the block size.But here we say NOPADDING.Dont they look contradictory.

Can we have arbitrary data which is not padded as input to ECB mode.

Alex Zielenski
  • 3,591
  • 1
  • 26
  • 44
crackerplace
  • 5,305
  • 8
  • 34
  • 42
  • Can we mark this Java as well whocares? That AES/ECB/NOPADDING looks suspiciously like a String that targets a Java cryptography provider (JCA/JCE). – Maarten Bodewes May 10 '12 at 20:01

1 Answers1

4

The "raw" modes of ECB encryption with no padding applied like for example AES/ECB/NOPADDING, are basically the pure application of the encryption function to N blocks of data. They are useful for developers that need to implement custom modes that are not shipped by default. Any mode of operation is somehow constructed from the raw encryption function.

Still, since a block cipher can only operate on full-length blocks, some form of padding has may have to be applied on the last block. This is left up to the developer, they will implement whatever form of padding is specified/recommended for the mode they wish to implement. There are many possibilities, and this is why we have "NOPADDING" - to leave the choice of padding up to us.

These modes, XXX/ECB/NOPADDING, should never be used directly. Neither should any ECB mode, really. Plain ECB encryption is very insecure, for example it doesn't hide statistical properties of the plaintext (you may know the examples where the "encrypted" image still looks much like the original). On top of that, as already noted, a block cipher can only operate on full-length blocks. This requires applying a custom padding scheme, which would add another layer where mistakes can be made as opposed to simply relying on some default implementation.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
emboss
  • 38,880
  • 7
  • 101
  • 108
  • When u mean raw modes of ECB ,are you referring to AES/ECB/NOPADDING ? – crackerplace May 10 '12 at 10:34
  • I tried to make things a little clearer - did this answer your question, too? – emboss May 10 '12 at 11:31
  • 7
    Very occasionally `NoPadding` mode is used for fixed length data that happens to match the block size of the cypher being used. This can be useful to reduce the size of network packets, especially if the messages are sent very frequently. – rossum May 10 '12 at 11:37
  • @rossum: For that purpose I would use a cipher mode that does not need padding, like CTR or GCM without authentication. – Robert May 10 '12 at 11:50
  • @rossum Good point, makes sense and will work if the underlying data is "random enough". – emboss May 10 '12 at 12:17
  • @emboss @ rossum .Also when the block length is not that of the cipher,assuming we are not padding,doesnt it cause any exceptions while encrypting.If no exceptions are thrown,then how is the last block of data encrypted as the corresponding cipher key bytes might not have corresponding bytes in the last input block to encrypt such as below Ex : Input Block : f o r ?? ?? ?? ?? ?? Cipher key : 6A 27 17 87 AB 88 83 F9 – crackerplace May 10 '12 at 12:23
  • @whokares Using CTR mode, or a Stream Cypher, the effective block size is one byte, so padding is not an issue. In more conventional modes, like ECB, an incorrect length will cause an exception. – rossum May 10 '12 at 12:52
  • @whokares In ECB mode it will indeed cause an error if the input doesn't match the block size. You need to apply some padding scheme to make it work. – emboss May 10 '12 at 13:21
  • @rossum & emboss alternatively, if you know the length of the plain text by other means (e.g. DER encoding, or static sized plain text packets) you may pad with any byte value, or "zero" padding. This happens e.g. when wrapping a private key using PKCS#8 (using CBC of course, not ECB) – Maarten Bodewes May 10 '12 at 19:56