jrihtarsic commented on code in PR #234: URL: https://github.com/apache/santuario-xml-security-java/pull/234#discussion_r1421994320
########## src/main/java/org/apache/xml/security/encryption/params/KeyDerivationParameter.java: ########## @@ -0,0 +1,42 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.xml.security.encryption.params; + +import java.security.spec.AlgorithmParameterSpec; + +/** + * This class contains the basic parameters used for key derivation. + */ +public class KeyDerivationParameter implements AlgorithmParameterSpec { Review Comment: The KDF API is wonderful news. I'm glad it will be included in a future Java SE. For the KeyDerivationParameter I will follow your suggestion and remove AlgorithmParameterSpec interface, even though I have a different perspective on this matter. I believe that KeyAgreement should be responsible for computing the final key, as example the DH is only a "base algorithm" for KeyAgreement computation. I also think that it would enhance the security if the computed shared secret (ZZ) never left the JCE implementation, as leaking ZZ could facilitate some attacks for deriving private key of recipient. Moreover, in ECDH_ES case, we need to safeguard the private key of the recipient, as compromising that key could lead to decrypting all previous encryptions. The reasoning: I think that it would be more convenient for developers to simply configure KeyAgreement with all standard parameters and obtain the final key from the JCE provider, as the ZZ is only an intermediate step in key agreement computation and developers usually does not need it. See also probably the very first KeyAgreement method standard definition (where the key agreement is not just computing the S): rfc2631 chapter: Diffie-Hellman Key Agreement Method "The first stage of the key agreement process is to compute a shared secret number, called ZZ ... The ZZ value is then converted into a shared symmetric cryptographic key" in practice for the second step the key derivation function is used - so the feature would not be useful only for xmlenc but also for other usages. See the: - NIST.SP.800-56Ar3 4.2 Key-Agreement Process - rfc8446 (TLS) Protocol Version 1.3: Chapter: 7.4.2. Elliptic Curve Diffie-Hellman - rfc7518 JSON Web Algorithms (JWA): Chapter: 4.6.2. Key Derivation for ECDH Key Agreement - rfc7748 Elliptic Curves for Security: Chapter: 6. Diffie-Hellman - W3C: https://www.w3.org/TR/xmlenc-core1/ : 5.6 Key Agreement ... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@santuario.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
