-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBxTCCAWECARIwDQYJKoZIhvcNAQECBQAwTTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJzb25hIENl
cnRpZmljYXRlMB4XDTkzMDQxMjIyNTI1N1oXDTk1MDQxMjA1MDAwMFowYzELMAkG
A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
VQQLExNQZXJzb25hIENlcnRpZmljYXRlMRQwEgYDVQQDEwtSYXltb25kIExhdTB5
MAoGBFUIAQECAgMAA2sAMGgCYQC4Lq5eHwr4u4bY7VggmpOwmyqhq9nMVR7VuaUy
4MOTPLPHi/dZM5E2gdODG1uV2YoGDNNTuVFRO4osQwxTOWMt9oEththrXOYI6oZ8
lzyYfmgLVL15S7HCV/GYJdlPuO0CAwEAATANBgkqhkiG9w0BAQIFAANPAAUVNpom
zLBp6r72gqG6bBU1eFbv9bNKk4WSQCXYRbulGmhyLCXItASYloprlBxKHm8EP178
P8z1rlbRNAoWw2G5q2550I6UUiJ5OOkVwB==
MIC-Info: RSA-MD5,RSA,
lTseoQ7YapjkRdsuA8YgFUP2MILA7WIMhLwyZVo2dvmYyeRewagzLzlm1cTwU74n
RIsG50Fa/RJmzxukw08ojOVuBeEfTO/h263Fm5lhvHrv1FHKuW2sCl5JgzhswK8d
Here're my more refined thoughts based on what I've read on this topic.
1. Without question, EDE is to be preferred over EEE. The remnants from
the "before DES was shown not to be a group," and hence the origin of
EDE, seem to be more widely understood and even in some use. I can see
no benefit for doing EEE over EDE.
2. EDE should be treated as a new cipher, in cookbook mode as Steve Kent
mentions, and CBC should be performed on the output of the whole thing.
To perform DES-CBC/encrypt followed by DES-CBC/decrypt followed by
DES-CBC/encrypt, which is what I think Carl is suggesting, does not offer
any proven benefit (and only marginal skeptical benefit) and is certainly
incompatible with any systems which may exist for doing EDE. Doing this
strange variant of CBC will probably raise more doubts than offer
reassurances.
3. Encrypted IVs. I agree that they cannot hurt, security-wise, but do not
feel that they contribute any added security except in the case where
no signature is included and hence the first block may be manipulated if
known to the attacker. To say that they help substantially in attacking
the first block implies that DES is vulnerable to known pt attacks and
my response would be to jump ship. Furthermore, non-encrypted IVs are
in conformance with PEM as it stands now.
4. 2 vs 3 keys. This one is the real toss up. While I feel comfortable with
2 keys security-wise, I do not see why we need to cripple ourselves by not
going the full 3 key route unless there're good compatibility reasons.
However, all indications are that the existing systems which use 2 keys
will not be used for PEM so we free to play this one as we wish. I am
tempted then to go for 3 keys.
5. On the identifier -- I agree with the proposals so far as they clearly
identify EDE and 3 keys. (Although the 3 looks out of place! :-)
6. On RSAREF interfaces -- I don't think that's an important issue worth
occupying bandwidth on this list.
-Ray
-----END PRIVACY-ENHANCED MESSAGE-----
Created with RIPEM Mac.