krb5_dbe_def_encrypt_key_data stores the salt type and value whenever "keysalt->type > 0", which in practice means whenever the salt type is not KRB5_KDB_SALTTYPE_NORMAL. But the salt value is only actually used by krb5_dbe_compute_salt if the salt type is KRB5_KDB_SALTTYPE_SPECIAL. Storing the salt value is pointless for the "norealm", "onlyrealm", and "afs3" salt types. The "v4" salt type uses an empty salt, so it doesn't matter there. The attached patch changes krb5_dbe_def_encrypt_key_data to only store the salt value if the salt type is KRB5_KDB_SALTTYPE_SPECIAL. I am storing it here for posterity, but I don't think we will push it to master for these reasons: * The space savings is not terribly significant for most deployments, because the norealm/onlyrealm/afs3 salt types aren't commonly used. * It would interact badly with #7918; unpatched KDCs using LDAP would stop honoring the norealm/onlyrealm/afs3 salt types encoded with newer KDC code. * There is (as always) some risk that my analysis is wrong. Ordinarily we take that risk all the time, but given the marginal nature of the benefits, there's not much reason to take that risk here. I am immediately marking this as resolved with keyword nochange, which is our equivalent of a WONTFIX issue.