Firebird Security Patch: Replacement of use of SHA-1 in the SRP Client Proof with SHA-256
In Summary : This proposed patch results from a security review of the Firebird SRP-6a implementation taking into account current NIST gui...
https://updatesinfosec.blogspot.com/2018/06/firebird-security-patch-replacement-of.html
In Summary :
This proposed patch results from a security review of the Firebird SRP-6a implementation taking into account current NIST guidance on the use of SHA-1 - see NIST Special Publication 800-131A, Revision 1, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (http://dx.doi.org/10.6028/NIST.SP.800-131Ar1) chapter 9. This guidance disallows the general use of SHA-1 for "Digital Signature Generation" whilst permitting continued use for "Digital Signature Verification".
Review of the Firebird SRP implementation appears to indicate that most uses of SHA-1 continue to be permitted under NIST guidance except for its use in generating the client proof. The SRP client proof may be characterised as a "Poor Man's Digital Signature" in that it provides a two party proof of identity rather than the third party proof normally expected from a Digital Signature i.e. it is not a non-repudiable proof. Nevertheless, it is believed that generation of the client proof falls under the heading of "Digital Signature Generation" when considering the NIST Guidance.
Continued use of SHA-1 in order to generate the client proof appears to risk leakage of the shared session key used to encrypt "over-the-wire" encryption and which hence also provides peer entity authentication during the lifetime of the connection. This may result in an attacker being able to monitor confidential communication either during the connection or at some later date and this could include leakage of an encryption key used to encrypt the user database, if this is passed from client to server during the connection.
Such an attack is viable if weaknesses in SHA-1 can be exploited to allow a brute force attack on the client proof to be computationally feasible. All parts of the message on which the client proof is based may be known to an attacker with the exception of the shared session key and such an attack would concentrate on revealing this key. If it were possible to reveal the shared session key in real time then additionally a man-in-the-middle attack would be feasible. [...]
kindly refer the following link as follow up :
https://ift.tt/2LSp88b
This proposed patch results from a security review of the Firebird SRP-6a implementation taking into account current NIST guidance on the use of SHA-1 - see NIST Special Publication 800-131A, Revision 1, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (http://dx.doi.org/10.6028/NIST.SP.800-131Ar1) chapter 9. This guidance disallows the general use of SHA-1 for "Digital Signature Generation" whilst permitting continued use for "Digital Signature Verification".
Review of the Firebird SRP implementation appears to indicate that most uses of SHA-1 continue to be permitted under NIST guidance except for its use in generating the client proof. The SRP client proof may be characterised as a "Poor Man's Digital Signature" in that it provides a two party proof of identity rather than the third party proof normally expected from a Digital Signature i.e. it is not a non-repudiable proof. Nevertheless, it is believed that generation of the client proof falls under the heading of "Digital Signature Generation" when considering the NIST Guidance.
Continued use of SHA-1 in order to generate the client proof appears to risk leakage of the shared session key used to encrypt "over-the-wire" encryption and which hence also provides peer entity authentication during the lifetime of the connection. This may result in an attacker being able to monitor confidential communication either during the connection or at some later date and this could include leakage of an encryption key used to encrypt the user database, if this is passed from client to server during the connection.
Such an attack is viable if weaknesses in SHA-1 can be exploited to allow a brute force attack on the client proof to be computationally feasible. All parts of the message on which the client proof is based may be known to an attacker with the exception of the shared session key and such an attack would concentrate on revealing this key. If it were possible to reveal the shared session key in real time then additionally a man-in-the-middle attack would be feasible. [...]
kindly refer the following link as follow up :
https://ift.tt/2LSp88b
