<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 21/07/2015 22:07, Michaela
Schoenbauer wrote:<br>
</div>
<blockquote cite="mid:55AEA67B.4060904@gmx.at" type="cite">Hi,
<br>
<br>
I'm currently working on my Master thesis, and the topic is about
ECDSA implementations and DSA implementations in the context of
small embedded systems.
<br>
<br>
I'd like to try out OpenSSL but I'm not sure if I can configure it
to be small enough for the embedded devices I use.
<br>
For my purpose a custom built of the library should exclude all
SSL/TLS functionality and only include (a) ECDSA support and (b)
DSA support in another built.
<br>
<br>
Does anyone know how small I can make the OpenSSL library? May the
results be smaller than 10KB or which results can I expect?
<br>
<br>
If anyone already tried something similar or has some
answers/hints I would be thankful.
<tt><br>
</tt></blockquote>
<tt>Unfortunately, since the introduction (many years ago) <br>
of the EVP interface abstraction, it has gotten a lot <br>
harder to link libcrypto (the non-SSL part of OpenSSL) <br>
with just a few algorithms and little else.</tt><tt><br>
</tt><tt><br>
</tt><tt>Best chance is to:</tt><tt><br>
</tt><tt><br>
</tt><tt>1. Use OpenSSL 1.0.2, not the future 1.1.0 which has <br>
removed some of what you need for this.</tt><tt><br>
</tt><tt><br>
</tt><tt>2. Build OpenSSL as "static" libraries, not as "shared <br>
libraries"/DLLs.</tt><tt><br>
</tt><tt><br>
</tt><tt>3. Use the "raw" ecdsa/dsa functions from ecdsa.h/dsa.h</tt><tt><br>
</tt><tt><br>
</tt><tt>4. Write your test program to only do the signing OR <br>
verification, not the key generation or other <br>
functions.</tt><tt><br>
</tt><tt><br>
</tt><tt>5. Write your test program to operate directly on the <br>
internal structures so you don't need the code space <br>
for the i2d/d2i conversion functions.</tt><tt><br>
</tt><tt><br>
6. Use linker diagnostics and/or object dumper programs <br>
to see which functions and source files get linked <br>
into your embedded binary.<br>
<br>
</tt><tt>7. Look at the actual implementation code in the OpenSSL <br>
source code to see if there is even more that can be <br>
trimmed out, e.g. by splitting some source files that <br>
contain multiple functions so one file contains the <br>
functions you use, and another file ther other.</tt><tt><br>
</tt><tt><br>
</tt><tt>8. Look at the actual ecdsa/dsa implementation code to <br>
see if it invokes the RNG for each signature or uses <br>
a cryptographic formula to deterministically generate <br>
a message/key dependent adversary unknowable <br>
per-signature key. <br>
This makes a big size difference because the RNG <br>
itself needs so much non-dsa code.</tt><tt><br>
</tt><tt><br>
</tt><tt>9. For ecdsa, look at the implementation code to see <br>
if it branches into different implementations <br>
depending on the curve used for the public/private <br>
key pair. If so, create a special version <br>
supporting only the curve you use for your test.</tt><tt><br>
</tt><tt><br>
</tt><tt>With all this, you might be able to get a code size a <br>
lot smaller than what you would get by just following <br>
the official guides on how to do the same operation <br>
with supported high level functions. But I am not <br>
at all sure if you can still get as low as you need.</tt><tt><br>
</tt><tt><br>
</tt><tt>A completely different approach is to just cut and <br>
paste snippets from the OpenSSL ecdsa/dsa code and <br>
hand optimize it for minimum size.</tt><br>
<br>
<tt>As another datapoint for your investigation, the <br>
ECDSA-like </tt><tt>signature scheme recently promoted by <br>
D.J.Bernstein </tt><tt>apparently hand optimized assembler <br>
code, yet I seem to recall it being larger </tt><tt>than <br>
10Kio code.</tt><br>
<br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>