Subject: [Cfrg] Trusting government certifications of cryptography

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Oct 2014 11:10:24 -0000

Torsten Schuetze writes:
> Smart cards, i.e., its coprocessors and its ECC software
> implementations, are always certified by Common Criteria, usually with
> rather high assurance level. Don't you trust this certification in
> principle? 

http://smartfacts.cr.yp.to explains how we factored 184 RSA-1024 keys
from Taiwan's national "Citizen Digital Certificate" database. As you
can see from http://smartfacts.cr.yp.to/cert.html, these keys were
generated by government-issued smart cards that advertised all of the
usual Common Criteria and FIPS certifications from BSI, NIST, and CSE.

http://smartfacts.cr.yp.to/analysis.html analyzes five contributing
factors to this security disaster---low-quality hardware RNG, inadequate
sanity checks, no run-time sanity checks, no postprocessing, and
inadequate initial response---and the complete failure of certification
to prevent the disaster from occurring.

Another interesting example to consider is the FIPS certification for
branches of OpenSSL starting with openssl-fips-1.1.2.tar.gz (2007). The
pursuit of FIPS certification was the reason that OpenSSL added support
for Dual EC with NSA's P and Q. The certification procedure failed to
catch the fact that OpenSSL's Dual EC implementation didn't work at all:

   https://www.mail-archive.com/[email-masked]/msg00127.html

As Steve Marquess put it: "Frankly the FIPS 140-2 validation testing
isn't very useful for catching 'real world' problems."

After the public learned that Dual EC with this P and Q was an NSA back
door (see, e.g., https://projectbullrun.org/dual-ec), the slowness of
recertification stopped openssl-fips from dropping Dual EC support for
_nine months_:

   https://www.mail-archive.com/[email-masked]/msg75061.html

It's clear that OpenSSL's certification had various other effects, such
as diverting quite a bit of OpenSSL funding into InfoGard Laboratories
Inc. How much positive security impact did this have to outweigh its
obvious negative impacts? For example, how many of OpenSSL's security
holes, whether in the FIPS version or generally, were discovered through
the FIPS validation process?

Security review is of course important, and I've heard several stories
of security problems being caught by Common Criteria testing labs. But
the security problems that _aren't_ caught show that certification is
not true "assurance" of security---even in relatively simple settings
such as the Taiwanese Citizen Digital Certificates, never mind the much
more complex environment of Internet cryptography.

I understand that words such as "certification" and "validation" and
"assurance" have an important impact on users in some markets. But for
experts it should be clear that more skepticism is warranted. You can't
reasonably ask CFRG to "trust this certification in principle".

---Dan

---

From: David Jacobson <[email-masked]>
Date: Fri, 03 Oct 2014 09:19:24 -0700

On 10/3/14, 4:10 AM, D. J. Bernstein wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>
I totally agree with Dan.  I've been involved in getting several 
products validated at FIPS 140-2 some at level 3 and some at level 1.  
Here are some examples of unnecessary difficulty and/or weaknesses.  
Some of what I say is based on what our consultant told us, and I 
presume he knew standard better than we.

1.  In one product we were accelerating IPSEC.  In IPSEC the security 
associations in the kernel contain the keys in plaintext. But FIPS 140-2 
level 3 requires that all key material be encrypted as it crosses the 
security boundary. Our consultant advised us to just use a fixed, hard 
coded, AES key on both sides.  Apparently this is allowed.

2.  Random number generators are required to implement a "continuous 
test", which means that they have to check that no two consecutive 
generated random numbers are the same, and if this does occur they must 
enter an error state.   Apparently this requirement was written back in 
the days when RNGs were generated using SHA1 and always had the same 
size.  But this is not the case with, say, CTR_DRBG from SP 800-90A.  
Even if we neglect that, it (sort of) requires saving each output value 
until the next generate operation.  This spoils backtracking 
resistance.  For good backtracking resistance, we want to delete the 
delivered value as soon as possible.  The "sort of" is because we could 
compute the hash of each delivered value, and save that and compare with 
the hash of the next one.  But that adds a lot of extra cycles.  And 
this is a waste, since the NIST-recommeded DRBGs can only get stuck with 
cryptographically small probability. And even if the DRBG did get stuck, 
a better response would be to force an immediate reseed, rather than 
entering an error state.

3.  There is a requirement at level 3 that the "operator" log in using 
"identity-based" credentials.  Well, when the host operating system is 
providing crypto services, sometimes for the OS itself, who is the 
"operator"?  Solution:  The driver for the crypto card is.  We gave the 
driver some credentials.  The validation requirements only apply to the 
interface, and it sees an approved login protocol, so all is well.

4.  One of the onerous things is the self test requirements.  If you 
build the HASH-DRBG in hardware, you would think the running the known 
answer tests at each power-on would be an acceptable way showing the the 
logic hasn't rotted.  This would only require a way for the driver to 
push in a known entropy blob instead of getting entropy from the 
hardware entropy generator.   No.  The HASH-DRBG hardware contains a 
dedicated implementation of SHA-256.  You have to not only do the known 
answer test on the whole HASH-DRBG, but you also have to apply known 
answer tests to the internal dedicated SHA-256.  This adds a lot of 
complexity with no benefit.

Summary,  FIPS-140 is not a system level security assurance.  It is 
showing that a lot of rules are satisfied at and inside the "security 
boundary".

    --David Jacobson

---

From: "Torsten Schütze" <[email-masked]>
Date: Tue, 7 Oct 2014 10:15:03 +0200

> usual Common Criteria and FIPS certifications from BSI, NIST, and CSE.

Dan,

you may remember that we discussed this RNG topic at the eve of last
years CRYPTO at Santa Barbara.

Following the discussion in this and the other threads on CFRG, I
should have better re-phrased my original question into: Do you
distrust Common Criteria (or government certification, as you call it)
in principle? Background of the question was to find out where does
the individual trust boundary of Alyssa run.

Of course, I cannot (and I will not) speak on behalf of BSI or another
``government agency´´ or on behalf of an independent evaluation lab as
T-Systems GEI or on behalf of any other official lab/agency. But
believe me, these presentations/these revelations have been discussed
thoroughly inside the German RNG community.

What do we have?
- We have a rather old CC EAL4+ certificate from January 2004 and a
  Assurance Continuity Maintenance Report from September 2004.
  (BTW, the first link to the Maintenance Report on your web site is
  wrong. The mirror link works.)

This certificate claims that the smart card hardware RNG TOGETHER
WITH ACCOMPANYING SOFTWARE provides a class P2 high physical true RNG
according to AIS 31, Version 1, 25.09.2001. The relevant technical
guide is Killmann/Schindler: A proposal for: Functionality classes and
evaluation methodology for true (physical) random number generators,
Version 3.1, 25.09.2001.

- Then we have your nice research paper and talks from the mid/end of
  2013.

Of course, there was a major problem with this product. But this
doesn't mean necessarily that there is a major problem with the
certification / evaluation process.

P2 high requires that there are a) a startup test, b) a total failure
test, and c) a continuous on-line test. This is not surprising, but the
big difference, e.g., to NIST FIPS 140-2 is, that there must be a
so-called stochastic model, i.e., a ``Comprehensible and plausible
description of a mathematical model of the physical noise source and
the statistical properties of the digitised noise signal sequence
derived from it.´´ The on-line test has to be adapted specifically to
the stochastic model. Commonly this amounts in understanding your
entropy source (and not just passing statistical tests) and providing,
at best, lower bounds on the entropy. Or as Victor Fischer puts it: 
``It is quite easy to design a TRNG that will let the statistical
tests pass ... but it is much more difficult to know where the
randomness comes from and how much true randomness is there.´´

P2 high DOES NOT require that there is a cryptographic
post-processing of the internal random sequence (non-cryptographic
post-processing as von Neumann or Peres procedure does not count here).

So, obviously the mentioned product failed to implement an effective
total failure test and/or an effective continuous on-line test. 

The situation with RNGs is completely different with NIST FIPS.
Usually NIST is focused much more on deterministic RNGs, see the
infamous SP800-90A. Up to the publication of FIPS drafts SP800-90B and
SP800-90C you could not find much on entropy sources and their
evaluation.

(And with the last two FIPS drafts I see some problems, too. For
example, an entropy defect of order 2^{-64} can NEVER be estimated
experimentally. In AIS 31, we have now the requirement of an entropy
defect of less than 3E-03, practically E-4..E-5, i.e., average Shannon
entropy per bit exceeds 0.997. And for this estimate 2^30 random bits
are recommended to test. The full entropy sources from SP800-90B/C
would require such HUGE random data for estimating the defect
2^{-64}=5E-20 that this is practically impossible.)

At your website you wrote regarding FIPS mode or non-FIPS mode:
``However, this did not result in HICOS failing certification; it
merely resulted in extra words on the certificate saying that the
certificate was valid only when the card was "operated in FIPS
mode".´´

I presume that the card has been CC certified in FIPS mode. For CC we
only have 

``The confirmed assurance package is only valid on the condition that
      - all stipulations regarding generation, configuration and
        operation, as given in the following report, are observed,
      - the product is operated in the environment described, where
        specified in the following report.´´

This means, that the card has not been used properly, i.e., the
external preconditions have not been fulfilled. So, no problem with CC
certificate or CC process, but with individual usage.

By the way, the above mentioned certificate does only apply to the
smart card hardware. Usually, you either have a manufacturer library
for RSA with certificate or another CC certificate for operating
system and RSA application. I could not find anything like this at
your website. So the manufacturer/producer of the RSA application and
their evalution lab/certification THESE WERE THE PEOPLE TO BLAIM, NOT
THE CC EVAL LABS OF THE HARDWARE.

However, even I have some criticism on Common Criteria. It is much too
easy to define a Target of Evaluation that is too narrow, sometimes
almost meaningless. For example, when I see an IPsec product evaluated
where the public-key and the symmetric key coprocessors are not in the
TOE. Or, when the organizational security policies and assumptions are
too wide, even unrealistic. But this just means: The statement ``CC
certification exists´´ is not very meaningful alone, one has to read
the complete security problem definition.

Another problem I sometimes have with CC is their reliance on keeping
design documents confidential and getting AVA points. I do not
advocate to publish everything, but one should not get any points for
confidential user manuals, etc.

> sanity checks, no run-time sanity checks, no post-processing, and

I admit the low-quality RNG and the missing/ineffective tests.
However, I do not see ``the complete failure of certification´´, only
then when you can prove that a smart card used in the CC specified
mode has been compromised.

Further, the analyzed product was rather old. This is no excuse and
shall not impair your results. But current AIS 20/31 standards,
effective since 2011, see Killmann/Schindler: A proposal for:
Functionality classes for random number generators, version 2.0,
September 18, 2011, recommend a class PTG.3 generator, e.g., a hybrid
physical true random number generator, basically a P2 high (now PTG.2)
with cryptographic post-processing (DRG.3). This type of RNG is/will
be REQUIRED for all German so-called qualified digital signatures, see
BSI Algorithmenkatalog 2014 (Übersicht über geeignete Algorithmen,
Bekanntmachung zur elektronischen Signatur, Bundesnetzagentur).

A PTG.3 RNG would have made the attack impossible. Nevertheless,
your result from last year provided one good reasoning for me
explaining the need of PTG.3 RNGs to our non-technical management
(besides certification requirement facts) :-)

As you may have noticed I have only written about Common Criteria
certification. This is the process I have the most experience with.
FIPS certification in general, for example, FIPS 140-2 and RNG
certification specifically, for example, SP800-90A, are completely
different. FIPS 140-2 is, in my opinion, rather old nowadays. FIPS
140-3 drafts, even they more than 5 years old now, had some good
ideas. Specifically with respect to side-channel evaluation.

This leads us back to the original problem: Elliptic Curve
Cryptography and Certification. Dan, I am sure you know the BSI
Guidelines AIS 46 Minimum Requirements for Evaluating Side-Channel
Attack Resistance of Elliptic Curve Implementations as Tanja was one
of the co-authors. All that I'm saying is that one should consider, at
least for applications in hostile environments, the complete set of
attacks and countermeasures. And not only timing attacks.

Common criteria may not be sufficient in some areas. But at least, it
is better than nothing (or everything else we have). Our aim as
security researchers/practitioners should be to improve that process
and not to discredit it.

Of course, in a perfect university world it would be fine to disclose
anything

http://smartfacts.cr.yp.to/faq.html:
> We strongly recommend that the chip manufacturer publicly disclose
> full details of the RNG hardware in use and provide copies of the RNG
> hardware to researchers, allowing a thorough characterization of the
> physical failures of the RNG hardware on the 1024-bit cards and an
> analysis of the differences in the RNG hardware on the 2048-bit cards.  

and it would even interest me, personally. But what would happen if
you find something in millions of enrolled cards and cannot fix it
immediately? So, there are some differences between university and
industry.

> You can't reasonably ask CFRG to "trust this certification in
> principle".

What I do ask CFRG, is to consider established security evaluation as
Common Criteria as ONE BLOCK OF BUILDING TRUST. 

And what I would like to ask CFRG further, is to consider the
different, more general ``performance´´ requirements as formulated in 
http://www.ietf.org/mail-archive/web/cfrg/current/msg05105.html

Regards,

    Torsten

---

From: Watson Ladd <[email-masked]>
Date: Tue, 7 Oct 2014 07:27:09 -0700

> thoroughly inside the German RNG community.

This is not an isolated incident. Apple claims various things about
their certification (FIPS 140 lowest level), yet the core ECC
implementation does not validate points and has a timing+control flow
side channel. I'm sure we could find other problems with certified
products if we tried.

> THE CC EVAL LABS OF THE HARDWARE.

Why? The software can't make random numbers without the hardware. The
configuration issue is part of the problem: it's clear that people
don't understand the limits of the certification, or how to ensure
they are configuring things correctly. Taiwan had every incentive to
get this right and couldn't.

> attacks and countermeasures. And not only timing attacks.

Most applications are not smart-cards. I don't see why we need to take
a 50% performance hit on every TLS connection, for devices that are
generally deployed in specialized systems anyway. The argument that
some devices will need to do this doesn't convince me either: why
would they need to connect to arbitrary websites? Even if those are
true, what's wrong with the Brainpool curves for this purpose?

The quality of certification has nothing to do with this question:
it's entirely a question about the relevance of power-side channel
attacks to most ECC deployments.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Dirk Feldhusen <[email-masked]>
Date: Tue, 07 Oct 2014 18:08:48 +0200

> side channel. I'm sure we could find other problems with certified
OK, by a certifcation it cannot be guaranteed that the product is
unbreakable. The statement provides an estimate for the minimal effort
which is required to break it. I am no FIPS expert, but to my opinion
this example shows that a low level evaluation is not an adequate
measure to detect vulnerabilities on implementation level. Contrariwise
a CC EAL4 evaluation (or higher) requires the evaluator to get access to
the source code by ADV_IMP.

> get this right and couldn't.

The information how to use the product in a secure way is given in the
guidance which has to be delivered together with the product.
The smart card hardware is not able to make every possible software on
it secure, so you need also a certificate for the RSA implementation,
which implies that the software uses the hardware properly.

> attacks to most ECC deployments.
To exclude the possibilty of power or EM side channel you need the
assumption that the attacker has no physical access to the device.
As I understand Torsten the main problem here are special primes which
are harder to secure against such side channel leakage.

---

From: Michael Hamburg <[email-masked]>
Date: Tue, 7 Oct 2014 09:55:33 -0700

> On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen <[email-masked]> wrote:

> are harder to secure against such side channel leakage.

Are they actually harder to secure (eg, requiring new countermeasures), or just slower on hardware which doesn’t accelerate the special prime (eg, by requiring longer blinding factors)?

— Mike

---

From: Dirk Feldhusen <[email-masked]>
Date: Wed, 08 Oct 2014 10:04:53 +0200

Am 07.10.2014 18:55, schrieb Michael Hamburg:
>
>> On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen
>> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Are they actually harder to secure (eg, requiring new
> countermeasures), or just slower on hardware which doesn’t accelerate
> the special prime (eg, by requiring longer blinding factors)?
>
> — Mike

I agree to both. First, additive point (and scalar) blinding doesn't
work properly for a special prime ie adding a small multiple of the
prime leaves most parts of the binary representation of the point
coordinate unchanged (depends on the kind of the leakage, here it is
assumed that the Hamming weight of single words leaks through the
multiplication). Of course other blinding methods could work. Second,
hardware designed for general primes doesn't accelerate special primes
as far as I know and inserting large blinding factors would slow it
further down. But this depends on the blinding method.

— Dirk

---

From: "Lochter, Manfred" <[email-masked]>
Date: Wed, 8 Oct 2014 13:57:02 +0200

Mike,

in a nutshell: Yes, they are harder to secure.

Long version: There are theoretical arguments that show that blinding becomes 
harder for special primes:

One of the proposed countermeasures against side-channel attacks on the point 
multiplication is Coron's first countermeasure \cite{Coron99}. 
Instead of computing $\lambda P$ one chooses a random number $r$ (usually $r$ 
has 32 bits, \cite{Coron99} suggests using 20 bits) 
and computes $(\lambda +r q)P.$
 It has been
observed (\cite{Ciet}(The main ideas from \cite{Ciet} are also reproduced in 
\cite{Ebeid}, which is easily available} and later 
independently in 
\cite{RandReps})
that the validity of this countermeasure relies on the structure of the binary 
representation of $p$. For cofactor one curves the upper half of 
the binary representation of $p$ coincides with the upper half of the 
representation of $q$ by the Hasse-Weil theorem.
If this part of $p$ contains long runs of zeroes or 
ones
(as e.g. for curves over fields with Pseudo-Mersenne characteristic, as the 
NIST curves, or over fields with special prime characteristic as 
$2^{255} -19$ over which curve25519 is defined) 
some bits of $r$ and $\lambda$ can directly be accessed through measurements. 

In \cite{SchiWi} it is even shown that for some curves even 64 bits blinding 
are not sufficient, depending on the 
error rate of the measurements. In addition an {\glqq alternate attack\grqq}\ 
is introduced  \glqq that cannot be prevented by 
increasing the parameter $R$\grqq \ within 
a reasonable range\footnote{In the notation of \cite{SchiWi} $R$ is the 
bitlength of the random number $r$}.

@inproceedings{Coron99,
    author = {Jean-Sebastien Coron},
    booktitle = {Cryptographic Hardware and Embedded Systems},
    title = {{Resistance against Differential Power Analysis for Elliptic 
Curve Cryptosystems}},
    year = {1999}
}
@ARTICLE{Ebeid,
    author = {Nevine Maurrice Ebeid},
    title = {{Key Randomization Countermeasures to Power Analysis Attacks on 
Elliptic Curve Cryptosystems}},
    journal = {Thesis},
    year = {2007},
    %volume = {12},
    %pages = {1--28}
}
  @misc{Ciet,
    author = {Mathieu Ciet},
    title = {Aspects of fast and secure arithmetics for elliptic curve 
cryptography},
    howpublished = {Thesis},
    year = {2003},
    }
@article{RandReps,
 title = "Randomised representations",
 author = "Elisabeth Oswald and Daniel Page and Nigel Smart",
 year = "2008",
 volume = "2",
 number = "2",
 pages = "19--27",
 journal = "IET Proceedings on Information Security",

 }
@ARTICLE{SchiWi,
    author = {Werner Schindler and Andreas Wiemers},
    title = {{Power Attacks in the Presence of Exponent Blinding} },
    journal = {Journal of Cryptographic Engeneering},
    year = {to appear},
    %volume = {12},
    %pages = {1--28}
}

__________ ursprüngliche Nachricht __________

Von:		Michael Hamburg <[email-masked]>
Datum:	Dienstag, 7. Oktober 2014, 18:55:33
An:		Dirk Feldhusen <[email-masked]>
Kopie:	"[email-masked]" <[email-masked]>, "D. J. Bernstein" <[email-masked]>
Betr.:	Re: [Cfrg] Trusting government certifications of cryptography

> Are they actually harder to secure (eg, requiring new countermeasures), or
> just slower on hardware which doesn’t accelerate the special prime (eg, by
> requiring longer blinding factors)?
>
> — Mike

-- 
Lochter, Manfred
--------------------------------------------
Bundesamt für Sicherheit in der Informationstechnik (BSI)
Referat K21
Godesberger Allee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Telefon: +49 (0)228 99 9582 5643
Telefax: +49 (0)228 99 10 9582 5643
E-Mail: [email-masked]
Internet:
www.bsi.bund.de
www.bsi-fuer-buerger.de

---

From: Mike Hamburg <[email-masked]>
Date: Wed, 08 Oct 2014 10:22:22 -0700

OK, thanks Manfred.

> some bits of $r$ and $\lambda$ can directly be accessed through measurements.
Right.  I was trying to understand whether the problem can be solved by 
using a longer blinding factor -- even blinding to $r ~ \sqrt q$ would 
be faster on systems that accelerate special primes -- or whether it 
becomes truly infeasible or impractical.
> bitlength of the random number $r$}.
This paper is paywalled, so I haven't read this paper beyond the first 
two pages, which describe the attack as working on RSA or ECC in general 
(with/without CRT).  But if they detail a way to attack realistic 
implementations of blinding on special primes and not general, even for 
long $r$, then I concede the point.

Thanks,
-- Mike

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Oct 2014 00:55:11 -0000

The "special primes are harder to secure than general primes" claims are
almost completely backwards.

The correct question is what level of security can be achieved within
the user's performance budget. Whether one counts hardware transistors,
FPGA slices, AVR cycles, ARM cycles, or Intel cycles, the simple fact
is that special primes are about half the cost of general primes (they
almost eliminate reduction cost, which is about half the cost of mulmod
and more than half the cost of a separate sqmod), leaving far more room
for adding defenses against side-channel attacks.

In the case of Brainpool's 256-bit curve, the defense under discussion
consists of obscuring the bits of a 256-bit scalar s by adding a small
multiple of the 256-bit group order to s, typically a 32-bit multiple.
This seems safe if the bits are further obscured by a considerable level
of physical noise. However, for plausibly smaller noise levels this is
breakable, as illustrated by the recent paper by Schindler and Wiemers.

This not-very-secure 288-bit Brainpool scalar multiplication is roughly
as expensive as a 576-bit scalar multiplication on NIST P-256, using a
320-bit multiple instead of a 32-bit multiple. Nobody knows how to break
a 320-bit multiple for the same plausible noise levels: the attacker
needs the noise levels to be considerably lower. Less expensive curves,
such as Curve25519, make room for even stronger side-channel defenses.

It's easy to see, and well known, that for NIST P-256 etc. there are
some scalar bits that wouldn't be obscured in this way if the multiple
were smaller than about 128 bits. But such small multiples are at levels
of performance that can't be achieved _at all_ by the Brainpool curves,
so talking about this as a Brainpool security advantage makes no sense.

The only reason I said "almost completely backwards" rather than
"completely backwards" is that there are a few unusual platforms that
have trouble seeing the cost advantages of special primes. For example,
if someone built typical RSA-acceleration hardware years ago and is
trying to resell it as ECC-acceleration hardware, he'll get

   * bad speeds out of Brainpool,
   * similarly bad speeds out of special primes,
   * worse speeds out of side-channel-protected Brainpool, and
   * even worse speeds out of side-channel-protected special primes.

He won't see that competently designed special-prime hardware meets the
user's performance goals with much stronger side-channel protection at
vastly lower cost. The picture here is not that special primes are
harder to secure than general primes; the picture is that special primes
are easier to secure than general primes, except on obsolete niche
hardware.

The new Brainpool paper http://eprint.iacr.org/2014/832 incorrectly
states that a "special shape of the prime does not improve performance
in hardware" if the hardware is designed to "support arbitrary primes".
In fact, anyone who can afford the hardware area for "arbitrary primes"
is very close to the hardware area for arbitrary primes _plus_ several
special primes. Mike Hamburg already gave an example last month:

   I have some limited experience in crypto hardware design, in
   particular working with a hardware modulo multiplier.  If I recall
   correctly, adding support for a handful of the NIST primes (192, 224,
   256 and 384 maybe?) cost about 10% area overhead in our lightweight
   design, for double the performance.

The huge speed advantage over Brainpool again turns into an advantage in
side-channel protection for any performance target, again contradicting
the "special primes are harder to secure than general primes" claim.

Of course, for ECC hardware designers who have more serious performance
constraints, supporting "arbitrary primes" is out of the question, and
choosing brainpoolP256t1 is much less pleasant than choosing a special
prime, particularly with a Montgomery curve. The special prime again
ends up with better side-channel protection for any performance target.

To summarize, the strongest hardware designs provide the maximum
side-channel protection by taking advantage of the speed of special
primes. The core Brainpool objection to these stronger hardware designs
is really that they don't match Brainpool's old designs. This is a
transition-cost objection, raising questions such as

   * which hardware we're actually talking about,
   * how much the hardware is used in IETF protocols today,
   * whether the hardware would really have trouble with new curves,
   * how expensive new hardware for the new curves would be,
   * whether this is outweighed by the costs of sticking to old curves,

etc. This shouldn't be misrepresented as a security objection.

---Dan

---

From: David Leon Gil <[email-masked]>
Date: Thu, 16 Oct 2014 21:25:30 -0400

> breakable, as illustrated by the recent paper by Schindler and Wiemers.

For folks less familiar with this issue, page 85 et seq. of (the
slides for) Marc Joye's FDTC 2013 keynote present a very readable
explanation of why additive blinding, as described above, doesn't
work:

http://conferenze.dei.polimi.it/FDTC13/shared/FDTC-2013-keynote-2.pdf

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 17 Oct 2014 07:16:39 +0100

On 17/10/2014 01:55, D. J. Bernstein wrote:

> This seems safe if the bits are further obscured by a considerable
> level of physical noise. However, for plausibly smaller noise
> levels this is breakable, as illustrated by the recent paper by
> Schindler and Wiemers.

In line with my previous comments, I'm just going to +1 all of this
message, but particularly this bit right here.

I also have a big question about whether wanting to minimise costs by
reusing certifications for existing RSA hardware - and reusing that
existing hardware for ECC - is necessarily sound in light of new
research, new information, serious concerns raised about the efficacy
and integrity of existing certification processes, wanting open
alternatives, not working well with the NIST curves either, and so on.

And there again is the point I made earlier: if they want Brainpool,
they've already _got_ Brainpool. Nobody else seems to want it. That's
why we're being asked for _new_ curves. And why they should design
_new_ hardware to support them. (And protect against 'new' threats.)

- -- 
/akr