Bouncy Castle provides 6 different paddings for padding messages.

However, I am not quite sure which one to choose from.

ISO10126d2, ISO7816d4, PKCS7, TBC, X923, ZeroByte.

Given that the native Bouncy Castle API requires the message to be greater than 114 bytes.

  • What could be the recommended padding to be used to pad the message?

  • What is the strength and weaknesses of each padding?

  • I would want to choose either X923 with RNG or ISO10126d2 but I am not really sure about that.

  • 3
    $\begingroup$ As far as I know those are padding methods for block ciphers, which ED448 is not. I am not familiar with BC too much, but check the API again... $\endgroup$
    – Amit
    Feb 5, 2023 at 23:17
  • $\begingroup$ If you provide your current code / ideas on Stack Overflow somebody could probably correct any mistakes. I'm a bit out of time at the moment, having plans for all evenings and a full workweek, so I might be able to respond Friday earliest. $\endgroup$
    – Maarten Bodewes
    Feb 6, 2023 at 13:40

1 Answer 1


You've specified padding modes for block ciphers. For block ciphers, the padding depends solely on the mode of operation and of course the block size. The paddings you mention are mainly for ECB & CBC mode of operation. Signatures however depend on a hash function, not on a block cipher. Hash functions usually perform some kind of padding internally, but that padding is not configurable.

Signatures may also pad the hash itself but that function is not intrinsic to signature schemes; a scheme without padding could well exist. For RSA we would regularly use the PKCS#1 v1.5 or PSS signature schemes, and these include a padding method of the same name (the precise names are mentioned in the PKCS#1 standard, but nobody uses that while discussing the schemes).

However, if we look at the definition of Ed448 signature scheme then we'll find the following algorithm description:

5.2.6. Sign

The inputs to the signing procedure is the private key, a 57-octet string, a flag F, which is 0 for Ed448, 1 for Ed448ph, context C of at most 255 octets, and a message M of arbitrary size.

  1. Hash the private key, 57 octets, using SHAKE256(x, 114). Let h denote the resulting digest. Construct the secret scalar s from the first half of the digest, and the corresponding public key A, as described in the previous section. Let prefix denote the second half of the hash digest, h[57],...,h[113].

  2. Compute SHAKE256(dom4(F, C) || prefix || PH(M), 114), where M is the message to be signed, F is 1 for Ed448ph, 0 for Ed448, and C is the context to use. Interpret the 114-octet digest as a little-endian integer r.

  3. Compute the point [r]B. For efficiency, do this by first reducing r modulo L, the group order of B. Let the string R be the encoding of this point.

  4. Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and interpret the 114-octet digest as a little-endian integer k.

  5. Compute S = (r + k * s) mod L. For efficiency, again reduce k modulo L first.

  6. Form the signature of the concatenation of R (57 octets) and the little-endian encoding of S (57 octets; the ten most significant bits of the final octets are always zero).

Here PH is the hash function used over the message which is a configuration option.

Note that there are two parts that could be considered padding: dom4(F, C) || prefix || PH(M) pads the hash with dom4(F, C) || prefix, and dom4(F, C) || R || A || PH(M) pads the hash with dom4(F, C) || R || A. However, neither of these two calculations are configurable (dom4 is an ASCII string, prefix is part of the hash output, R is a randomized point calculated from A and A is the public key (also a point).

All in all, no padding mode should have to be indicated for Ed448; you should just have to configure the PH, i.e. the message hash.

  • $\begingroup$ Could somebody please verify that I'm referencing the correct RFC? There seems to be a difference with Ed448-Goldilocks (the original paper) mentioned in the RFC itself. $\endgroup$
    – Maarten Bodewes
    Feb 6, 2023 at 11:09
  • 1
    $\begingroup$ You mean something like this? $\endgroup$
    – DannyNiu
    Feb 6, 2023 at 12:20
  • $\begingroup$ @DannyNiu Hmm, OK, I'm trying to see if this would have any impact but I don't think so; please notify me if you think differently on that. I see some new vectors in the RFC errata, which are being held for a version v2 of the RFC. $\endgroup$
    – Maarten Bodewes
    Feb 6, 2023 at 12:51
  • $\begingroup$ I understand now that signatures don't necessary need to input randomness into the message thanks to this link. (crypto.stackexchange.com/questions/61178/…). Now I think I will go for the padding in the link above or just use zero byte padding. $\endgroup$
    – Hern
    Feb 7, 2023 at 6:06
  • $\begingroup$ That's not the padding for the input message, that's for the hash in the signature. And it is to provide security specifically for RSA, it has nothing to do with Ed448. $\endgroup$
    – Maarten Bodewes
    Feb 7, 2023 at 9:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.