Required/recommended ciphers in H.235?

Paul Long plong at PACKETIZER.COM
Mon Sep 9 12:16:23 EDT 2002

H.235 says, "The session key encryption algorithm is the same as the
negotiated media encryption algorithm." At the very least, this of
course means that one uses the same cipher; however, there are some
important details that this statement overlooks, i.e., mode, IV, salt,
and padding. I assume that the guiding principle is to treat the ASN.1
encoded value as much like an RTP payload as possible.

Does one use the same mode as media and therefore the same block
processing for each successive block in the encoded ASN.1 value?

For H.235v3, one clearly uses the IV specified in the new type,
NewKeySyncMaterial.paramS. However, what does one do for v2? There
doesn't seem to be any way to specify the IV for session-key
encryption. I suppose one could derive it from the session key similar
to how SRTP derives stuff from the master key. For example, IV =
session key. Maybe this should go in the IG.

This is a tough one. One could have used the same salt being signaled
for media, but it is of course encrypted! Therefore, if the mode for
encrypting media is EOFB, which uses a salt value, and one is supposed
to use the same "encryption algorithm" for encrypting the session key
as encrypting media, what salt value does one use? An implied salt
value of all zeros would work, but this is not written down anywhere.

This is the toughest to translate from media to session-key encryption.
This is the overall H.235 statement as to what kind of padding to
perform on media: "Two methods are available to handle packets whose
payload is not a multiple of blocks: 1) Ciphertext Stealing for ECB and
CBC; Zero pad for CFB and EOFB. 2) Padding in the manner prescribed by
[RTP] (Section 5.1)." Since a session key isn't an RTP packet, we can
eliminate #2. Therefore, #1 says to use zero padding for EOFB and
ciphertext stealing for CBC. Is that how we handle padding when
encrypting the session key?


For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list