[OpenAFS] packet sniffing and file content

[Sam Hartman]

>>>>> "Ted" == Ted Anderson <ota@transarc.com> writes:
    Ted> I don't want to suggest that fcrypt() is great crypto, but
    Ted> until it can be replaced, I don't think is helpful to
    Ted> minimize the actual protection it provides.  It's short key
    Ted> size and vulnerability to differential cryptography are
    Ted> largely theoretical.  Unless an attacker can bring to bear
    Ted> significant resources (such as that required for a DES
    Ted> cracking engine[2]), fcrypt is probably safe.  

Perhaps.  However from a security standpoint I'd rather be much more
conservative and describe fcrypt as a weak cryptosystem not subjected
to significant public analysis.  Before your paper was released, I
don't think that many people outside of the AFS community had taken a
close look at fcrypt.


It certainly provides protection against trivial passive sniffing
attacks and probably provides more.  However, the security community
has a long-established and in my opinion justified tradition of being
very skeptical of new crypto that has not been reviewed by the crypto
community at large.  If we treat fcrypt as weak, the worst we will do
is cause people to take extra security steps or potentially to deploy
some solution other than AFS.  However if we are careful to point out
that (with the possible exception of Win2k CIFS), the other commonly
used options have worse security, then we can minimize the chances
that someone will fail to deploy AFS because of fcrypt.  If someone
deploys SFS or some other special purpose secure filesystem instead of
AFS, citing fcrypt, then they have probably made the right decision
for their environment.

I don't consider fcrypt adequate to protect kaserver incrementals but this
is generally not an issue because I'd rarely recommend using kaserver
in a new install.