public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: "Christophe Coutand" <ccoutand@stmi.com>
To: "Michael Bergandi" <mbergandi@gmail.com>,
		"eCos Developer List" <ecos-devel@ecos.sourceware.org>
Subject: RE: Open Cryptographic Framework (OCF) Interface for eCos
Date: Fri, 10 Dec 2010 11:10:00 -0000	[thread overview]
Message-ID: <D6050C555CC56940A7AF326522830276037D227D@mail2.STMIRV01.COM> (raw)
In-Reply-To: <AANLkTi=8x4OQ08cHi2YrmnsVVw1-tv2AxS575gT32R2Z@mail.gmail.com>

Hi,

We came across a similar problem few months ago. At that time I consider
writing a simple eCos IO layer that could handle multiple encryption
types but with only one consumer for each to make it simple. In the end
we ended up using the crypto engine without generic IO layer...

I have not looked at the details but the OCF core seems a good
alternative and the code is pretty self content (crypto.c) which should
make it easy to port.

Christophe

-----Original Message-----
From: ecos-devel-owner@ecos.sourceware.org
[mailto:ecos-devel-owner@ecos.sourceware.org] On Behalf Of Michael
Bergandi
Sent: 9. desember 2010 19:10
To: eCos Developer List
Subject: Open Cryptographic Framework (OCF) Interface for eCos

Hi all,

I am using ecos on a product that requires encryption. Our processor has
encryption engine hardware that we are going to leverage as much as
possible. The problem we found was that there really was no good place
to put the interface to our crypto engine in ecos. This is where OCF
comes
in.

Our current thought is that we could build out an OCF interface at the
io
layer in ecos. That would provide a common interface to various crypto
engines across many platforms. Hence, an application that uses crypto
that makes use of the OCF interface would be portable to any other
board that ecos is running on that may have a different engine, but
still
provides the same crypto functionality as needed by the app.

In the future, I see many crypto libs having to adopt some common
interface
to take advantage of hardware crypto engines. OCF seems to have good
momentum.

I would like to hear some thoughts or input on the following:

1. Does the io layer sound like the right place to do this?
2. Would this work be of interest to anyone else?
3. Would this work be a candidate for being included in the ecos tree?

Other thoughts and comments welcome as well.


-- 
Michael Bergandi

      reply	other threads:[~2010-12-10 11:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-09 18:10 Michael Bergandi
2010-12-10 11:10 ` Christophe Coutand [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D6050C555CC56940A7AF326522830276037D227D@mail2.STMIRV01.COM \
    --to=ccoutand@stmi.com \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=mbergandi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).