From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21831 invoked by alias); 10 Dec 2010 11:10:00 -0000 Received: (qmail 21555 invoked by uid 22791); 10 Dec 2010 11:09:40 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_05,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.stmi.com (HELO mail.stmi.com) (70.169.254.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Dec 2010 11:09:16 +0000 X-Ninja-PIM: Scanned by Ninja X-Ninja-AttachmentFiltering: (no action) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Open Cryptographic Framework (OCF) Interface for eCos Date: Fri, 10 Dec 2010 11:10:00 -0000 Message-ID: In-Reply-To: References: From: "Christophe Coutand" To: "Michael Bergandi" , "eCos Developer List" X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2010-12/txt/msg00005.txt.bz2 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. --=20 Michael Bergandi