Re: Avoiding C++ Templates In Cipher Implementation
From: David Hopwood (david.hopwood_at_zetnet.co.uk)
Date: 06/09/03
- Next message: Alex Vinokur: "Re: Avoiding C++ Templates In Cipher Implementation"
- Previous message: Brian Gladman: "Re: Gladman v. St Denis [aes code]"
- In reply to: Brian Gladman: "Re: Avoiding C++ Templates In Cipher Implementation"
- Next in thread: Brian Gladman: "Re: Avoiding C++ Templates In Cipher Implementation"
- Reply: Brian Gladman: "Re: Avoiding C++ Templates In Cipher Implementation"
- Reply: John E. Hadstate: "Re: Avoiding C++ Templates In Cipher Implementation"
- Reply: Ernst Lippe: "Re: Avoiding C++ Templates In Cipher Implementation"
- Reply: Michael Amling: "Re: Avoiding C++ Templates In Cipher Implementation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 09 Jun 2003 04:31:07 +0000
-----BEGIN PGP SIGNED MESSAGE-----
Brian Gladman wrote:
> "Russ Lyttle" <lyttlec@earthlink.net> wrote:
> [snip]
> > Code I write often must meet some combination of the following 3
> > requirements. : (1) It must be easy to maintain; (2) It must be proven
> > correct; or (3) it must be secure. Pick two.
> > (1) requires readable source and easily debugged execuitables. That means
> > any one can reverse engineer the object code. Thus less (3).
> > Templates make it difficult to meet requirement (2) even though they help
> > lots for meeting (1).
> > The crypto I do has (3) more important than (2) and often does not have to
> > meet (1) at all. The crypto algorithm must be correct.
>
> So you are happy to have incorrect code as long as it is secure?
>
> I personally doubt that (3) is achievable in the absense of (2) since
> assurance of security to a certain standard of proof will require proof of
> correctness to at least the same standard.
Correctness implies security (why would anyone consider an insecure system
to be correct?), but security does not imply correctness. For example, suppose
we have a system that should always produce a result, such that we can easily
demonstrate that it *either* produces a correct result or reports failure.
However, demonstrating that there is no input for which it can fail may be
very difficult. Provided that failure is reported in a secure way, and provided
that an attacker cannot influence whether the system fails, there is no reason
why we should not consider it to be secure.
I agree completely with Ernst Lippe's conclusion, though:
# I am absolutely convinced that readable source code is
# essential for all three requirements. If it is unreadable
# it is unmaintainable. If it is unreadable, how are you going
# to prove that it is correct? If you can't prove that it
# is correct why should you believe that it is secure?
More directly, if it is unreadable then it is unlikely we can demonstrate
to any useful degree of confidence that it is secure, regardless of whether
or not it is correct. ("Proof" is rarely possible and rarely required.)
> > Crypto devices should have lots of anti-tampering mechanisms. This is only
> > one.
>
> This might be a requirement but it will not always be necessary.
Agreed.
- --
David Hopwood <david.hopwood@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBPuQNgjkCAxeYt5gVAQFFHQf7B980JY0e1rlTglF7Gzi7dePdHJWZ099x
y9KjS9EJ10WtZQRhlV0zMdljLQ/iN2+snZNk55vAmdjngct1HdQaACJgzlSJCtV1
UV499gQFq4+uzxh8o9u4qvmUl/m50qxKvSnTjWRiaIWh6Up2T4PPKSG8/lLIgKTu
O1dEFb9U0SSt7/IMcEJWbFdTyuKjl5iF3EFF+0wjBjaqc3hx5xU82SEVORzmTFs9
FcL/b0N9/qAogdP1YSkLQ0mW1LaaL78R/h3EILs9qwnD9/+/m3TS7lp8yESHC1z7
FO9jaJrLnTz1JiEe2/2ppbWBNVnBofIJLOJukz/T5ONinMgp6n1UNA==
=mLRm
-----END PGP SIGNATURE-----
- Next message: Alex Vinokur: "Re: Avoiding C++ Templates In Cipher Implementation"
- Previous message: Brian Gladman: "Re: Gladman v. St Denis [aes code]"
- In reply to: Brian Gladman: "Re: Avoiding C++ Templates In Cipher Implementation"
- Next in thread: Brian Gladman: "Re: Avoiding C++ Templates In Cipher Implementation"
- Reply: Brian Gladman: "Re: Avoiding C++ Templates In Cipher Implementation"
- Reply: John E. Hadstate: "Re: Avoiding C++ Templates In Cipher Implementation"
- Reply: Ernst Lippe: "Re: Avoiding C++ Templates In Cipher Implementation"
- Reply: Michael Amling: "Re: Avoiding C++ Templates In Cipher Implementation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|