Le 04/01/16 06:12, Zheng, Kai a écrit :
> It's good to look at the life cycle of these decrypted objects but I don't
> think it will help a lot if we would do otherwise. Generally decrypting the
> part and using the decrypted result are not the same place.
Here is where the encrpted data is decrypetd and used, in KdcRequest :
/**
* Get the armor key.
*
* @throws org.apache.kerby.kerberos.kerb.KrbException e
* @param fastArmor krb fast armor
*/
private void armorApRequest(KrbFastArmor fastArmor) throws
KrbException {
if (fastArmor.getArmorType() == ArmorType.ARMOR_AP_REQUEST) {
ApReq apReq = KrbCodec.decode(fastArmor.getArmorValue(),
ApReq.class);
...
Authenticator authenticator =
EncryptionUtil.unseal(apReq.getEncryptedAuthenticator(),
encKey, KeyUsage.AP_REQ_AUTH, Authenticator.class);
EncryptionKey armorKey =
FastUtil.cf2(authenticator.getSubKey(), "subkeyarmor",
encKey, "ticketarmor");
setArmorKey(armorKey);
}
}
or in TgsRequest :
public void verifyAuthenticator(PaDataEntry paDataEntry) throws
KrbException {
ApReq apReq = KrbCodec.decode(paDataEntry.getPaDataValue(),
ApReq.class);
...
Authenticator authenticator =
EncryptionUtil.unseal(apReq.getEncryptedAuthenticator(),
encKey, KeyUsage.TGS_REQ_AUTH, Authenticator.class);
...
In both case, we get the encrypted data, we decypt it locally, put the
result in a local variable, which is immediately used and discarded. Its
quite what I'm expecting to see, btw. At no point in the whole kerby
code we use the decrypted value, which is by the way not set in the
encapsulating data structure.
At this point, I can see why it has been added in the structure - in the
spirit that it may be used in a different place in the code than where
it has been decrypted -. But actually, this is not the case.
If you feel like it's better to keep those fields in the classes, so be
it. I'm just afraid we keep them for the sake of keeping them, not
respecting the YAGNI principle
(https://en.wikipedia.org/wiki/You_aren't_gonna_need_it)
Your call !
