RE: Linux CryptoAPI Userspace API proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Herbert,

We re-work part of the user space API. I would like to run it by you for
comment:

The Linux CryptoAPI User Interface behaves as follow:

1. User access via file descriptor /dev/crypto
2. Each opened file dscriptor represents a tfm
3. Algorithm and properties are set via an I/O control function call.
4. Algorithm name is string based and other properties are the same as
before
5. Use I/O control for per operation such as encrypt, decrypt, compress,
PKA, and hashing.
5a. Synchrnous call supports only (for the moment) as asynchronous
requires notification and complicates the design
5b. Operation destinction/result is byte pointer based, which can be
in-line
5c. Use direct I/O (no memory copy between user space and kernel space,
except key, hash result, IV, and associated data)

We will be submitting soon...

-Loc 

-----Original Message-----
From: Herbert Xu [mailto:herbert@xxxxxxxxxxxxxxxxxxx] 
Sent: Monday, May 19, 2008 9:01 PM
To: Loc Ho
Cc: Evgeniy Polyakov; Sebastian Siewior; Shasi Pulijala;
linux-crypto@xxxxxxxxxxxxxxx
Subject: Re: Linux CryptoAPI Userspace API proposal

On Thu, May 15, 2008 at 01:16:03PM -0700, Loc Ho wrote:
> 
> Linux Crypto User Space Interface Requirement:
> 
> 1. Support crypto and hashing/digest
> 2. Flexible to support compression in the future 3. Flexible to 
> support PKA (public key acceleration) in the future

I think extensibility as you've noted is really important.

As the crypto API is really an algorithm API, please make this interface
generic enough so that adding new (potentially non-crypto) operations is
easy.

> 4. A file descriptor per algorithms
> 5. Key and algorithm attributes provided by user space application
> (caller)

I would say that a file descriptor per tfm would make more sense.

> 8. Support cancel a pending operation for user space caller

We don't need to be able to cancel a specific operation.  The ability to
free a tfm and thereby flushing all requests associated with it should
be enough.

> 3. The type of algorithm, key, and other attributes are selected via 
> IO control call. This will be a single call.

Being a single call doesn't matter too much here because this is the
slow path.

> 5. Interface for per operation (such as encrypt, decrypt, compress, 
> PKA, and hashing)

It might be useful to consider an interface that allowed in-place
operations.

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux