Re: what is the size of a message encrypted with ECIES

According to John Doe <john.doe@xxxxxxxxxx>:
I'm not really a mathematician, so I didn't understand fully what you
described. I guess I still need much research understanding what ECC
is about.

If you need to implement ECC yourself, then you will need to understand
some of the mathematics behind it: enough to compute values in finite
fields, at least. "A Course in Number Theory and Cryptography", by Neal
Koblitz, is a good book for that.


The idea is that the protocol should be able to remain the same for
decades, so that's why I want to choose the biggest key size to
increase security. I've quickly read a few recommendations by NSA,
NIST, & other fellows, which talk about 2030 & beyond. That's what I'm
looking for. :)

It is a bit hard to predict technological advances beyond, say, a dozen
years. For the last few decades, computing power available for a given
price has steadily risen, and network bandwidth has also risen, actually
much faster. Whether the algorithms and key size you choose today will
still be secure in 25 years is debatable. It seems plausible, however,
that the constraints which make you hunt for bits today will have been
quite mollified by that time.

For instance, you may note that a 1000$ personal computer from 25 years
ago provided less computing power and less network bandwidth than a
1$ smartcard of 2008.

What looks like a good idea is to make your protocol extensible. For
instance, add a byte somewhere which identifies the algorithm. Right
now, set this byte to 1, to state that you use the key algorithms and
key sizes that you are about to choose. If, five years from now, you
need to update things (bigger keys, another MAC agorithm, whatever),
then you just have to allocate a new value (say 2) and then design that
new protocol with regards to the constraints you will have at that time.
When protocols evolve as such, you may gradually deprecate and then
cease to accept older versions. One identifier byte is rarely a big
price to pay for such flexibility.


Also, could I just drop the MAC ?

In general and in particular, no.

In particular: the presence of the MAC is important for all the security
proofs which have been described for ECIES. It protects message
integrity (which is an important goal either -- it takes a very special
threat model to be able to disregard attacks to integrity) but also
prevents a bunch of active attacks, where the attacker uses the
decryption party in devious ways.

In general: you should not fiddle with cryptographic protocols. They are
subtle beasts, and every detail is quite important. And, more
importantly, weaknesses are almost never obvious. You cannot test by
yourself whether your variant is weak or not. The only known test for
that is to give the variant to a bunch of cryptographers, stir them up,
and then let cook for a few years.


Well, is there any "ECIES for the dummies" paper available online ? I
must have seen dozens of PDF files describing different versions of
ECIES, each with its own names for each figure. :-S

To my knowledge, there is no standard describing ECIES with all its
industrial and practical details. There is one for RSA, it is called
PKCS#1, and it is quite good because it tells where each bit should
go and how the implementation should perform to be interoperable.

This means that if you want to use ECIES, then you will have to become
fluent in the underlying mathematics, so that you may define your own
protocol with all the details that have not been standardized. Koblitz's
book may help. IEEE p1363 may also give some helpful information on how
to compute operations on elliptic curves, how to represent points and so
on (especially annexes A and E). That standard is not free, the IEEE may
sell it to you (apparently for 132$) but you may find some drafts
around, the Internet being such a big place. For instance, try to google
for "P1363-A-11-12-99.pdf" (that's the annex A for draft version from
december 1999). As far as I know, there was a bit of feud when IEEE
decided not to make the standard freely available, because many of the
contributors did contribute under the implicit assumption that the
result would be free for everybody. Anyway, 132$ is not that much for
many corporate bodies.


--Thomas Pornin
.

Relevant Pages

  • Re: Slow network
    ... >> NFS isn't the fastest protocol in the world. ... The default packet size ... I thought that NFS was the 'standard' ...
    (uk.comp.os.linux)
  • Re: =?windows-1252?Q?=3F=3F=3F=3F=3F=3A_=5BPATCH_10/10=5D_?= =?windows-1252?Q?ieee802154=3A_
    ... Maxim Osipov wrote: ... standard is a less known name, ... I'll tack on tosmac (the tinyos protocol). ... The platforms I support have out of kernel support for a cc2420 radio ...
    (Linux-Kernel)
  • Re: Question on select() and sockets
    ... protocol') and RFC791. ... You were refering to an 'UDP standard', and that's what I was writing ... But I never claimed that was the only relevant standard. ... response', too: The behaviour you were writing about is not specified ...
    (comp.unix.programmer)
  • Re: Still An APP?
    ... In the link above, Igor Tandetnik writes: ... custom protocol, say myhttp: (but not for a standard one, see ). ...
    (microsoft.public.inetsdk.programming.webbrowser_ctl)