Skip to content

GitLab

Switch branch/tag
  1. 29 Aug, 2008 3 commits
  3. 15 Jul, 2008 1 commit
  5. 10 Jul, 2008 4 commits
  7. 21 Apr, 2008 3 commits
  9. 23 Feb, 2008 1 commit
  11. 10 Jan, 2008 9 commits
  13. 10 Oct, 2007 8 commits
    • Sebastian Siewior's avatar
      [CRYPTO] sha: Load the SHA[1|256] module by an alias · ad5d2789
      Sebastian Siewior authored 
      
Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto API can choose the best one
depending on its priority.

Additionally it ensures that the generic implementation as well as the
HW driver (if available) is loaded in case the HW driver needs the
generic version as fallback in corner cases.

Also remove the probe for sha1 in padlock's init code.

Quote from Herbert:
  The probe is actually pointless since we can always probe when
  the algorithm is actually used which does not lead to dead-locks
  like this.
Signed-off-by: default avatarSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      ad5d2789
    • Sebastian Siewior's avatar
      [CRYPTO] aes: Rename aes to aes-generic · f8246af0
      Sebastian Siewior authored 
      
Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto API can choose the best one
depending on its priority.

Additionally it ensures that the generic implementation as well as the
HW driver (if available) is loaded in case the HW driver needs the
generic version as fallback in corner cases.
Signed-off-by: default avatarSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f8246af0
    • Sebastian Siewior's avatar
      [CRYPTO] des: Rename des to des-generic · c5a511f1
      Sebastian Siewior authored 
      
Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto API can choose the best one
depending on its priority.
Signed-off-by: default avatarSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c5a511f1
    • Rik Snel's avatar
      [CRYPTO] xts: XTS blockcipher mode implementation without partial blocks · f19f5111
      Rik Snel authored 
      XTS currently considered to be the successor of the LRW mode by the IEEE1619
workgroup. LRW was discarded, because it was not secure if the encyption key
itself is encrypted with LRW.

XTS does not have this problem. The implementation is pretty straightforward,
a new function was added to gf128mul to handle GF(128) elements in ble format.
Four testvectors from the specification
	http://grouper.ieee.org/groups/1619/email/pdf00086.pdf


were added, and they verify on my system.
Signed-off-by: default avatarRik Snel <rsnel@cube.dyndns.org>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f19f5111
    • Herbert Xu's avatar
      [CRYPTO] aead: Add authenc · 3c09f17c
      Herbert Xu authored 
      
This patch adds the authenc algorithm which constructs an AEAD algorithm
from an asynchronous block cipher and a hash.  The construction is done
by concatenating the encrypted result from the cipher with the output
from the hash, as is used by the IPsec ESP protocol.

The authenc algorithm exists as a template with four parameters:

	authenc(auth, authsize, enc, enckeylen).

The authentication algorithm, the authentication size (i.e., truncating
the output of the authentication algorithm), the encryption algorithm,
and the encryption key length.  Both the size field and the key length
field are in bytes.  For example, AES-128 with SHA1-HMAC would be
represented by

	authenc(hmac(sha1), 12, cbc(aes), 16)

The key for the authenc algorithm is the concatenation of the keys for
the authentication algorithm with the encryption algorithm.  For the
above example, if a key of length 36 bytes is given, then hmac(sha1)
would receive the first 20 bytes while the last 16 would be given to
cbc(aes).
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3c09f17c
    • Herbert Xu's avatar
      [CRYPTO] api: Move scatterwalk into algapi · e962a653
      Herbert Xu authored 
      
The scatterwalk code is only used by algorithms that can be built as
a module.  Therefore we can move it into algapi.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e962a653
    • Herbert Xu's avatar
      [CRYPTO] api: Add aead crypto type · 1ae97820
      Herbert Xu authored 
      
This patch adds crypto_aead which is the interface for AEAD
(Authenticated Encryption with Associated Data) algorithms.

AEAD algorithms perform authentication and encryption in one
step.  Traditionally users (such as IPsec) would use two
different crypto algorithms to perform these.  With AEAD
this comes down to one algorithm and one operation.

Of course if traditional algorithms were used we'd still
be doing two operations underneath.  However, real AEAD
algorithms may allow the underlying operations to be
optimised as well.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1ae97820
    • Hye-Shik Chang's avatar
      [CRYPTO] seed: New cipher algorithm · e2ee95b8
      Hye-Shik Chang authored 
      
This patch adds support for the SEED cipher (RFC4269).

This patch have been used in few VPN appliance vendors in Korea for
several years.  And it was verified by KISA, who developed the
algorithm itself.

As its importance in Korean banking industry, it would be great
if linux incorporates the support.
Signed-off-by: default avatarHye-Shik Chang <perky@FreeBSD.org>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e2ee95b8
  15. 13 Jul, 2007 2 commits
    • Dan Williams's avatar
      async_tx: add the async_tx api · 9bc89cd8
      Dan Williams authored 
      The async_tx api provides methods for describing a chain of asynchronous
bulk memory transfers/transforms with support for inter-transactional
dependencies.  It is implemented as a dmaengine client that smooths over
the details of different hardware offload engine implementations.  Code
that is written to the api can optimize for asynchronous operation and the
api will fit the chain of operations to the available offload resources. 
 
	I imagine that any piece of ADMA hardware would register with the
	'async_*' subsystem, and a call to async_X would be routed as
	appropriate, or be run in-line. - Neil Brown

async_tx exploits the capabilities of struct dma_async_tx_descriptor to
provide an api of the following general format:

struct dma_async_tx_descriptor *
async_<operation>(..., struct dma_async_tx_descriptor *depend_tx,
			dma_async_tx_callback cb_fn, void *cb_param)
{
	struct dma_chan *chan = async_tx_find_channel(depend_tx, <operation>);
	struct dma_device *device = ch...
      9bc89cd8
    • Dan Williams's avatar
      xor: make 'xor_blocks' a library routine for use with async_tx · 685784aa
      Dan Williams authored 
      
The async_tx api tries to use a dma engine for an operation, but will fall
back to an optimized software routine otherwise.  Xor support is
implemented using the raid5 xor routines.  For organizational purposes this
routine is moved to a common area.

The following fixes are also made:
* rename xor_block => xor_blocks, suggested by Adrian Bunk
* ensure that xor.o initializes before md.o in the built-in case
* checkpatch.pl fixes
* mark calibrate_xor_blocks __init, Adrian Bunk

Cc: Adrian Bunk <bunk@stusta.de>
Cc: NeilBrown <neilb@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      685784aa
  17. 02 May, 2007 2 commits
  19. 06 Feb, 2007 3 commits
  21. 07 Dec, 2006 3 commits
    • Rik Snel's avatar
      [CRYPTO] lrw: Liskov Rivest Wagner, a tweakable narrow block cipher mode · 64470f1b
      Rik Snel authored 
      Main module, this implements the Liskov Rivest Wagner block cipher mode
in the new blockcipher API. The implementation is based on ecb.c.

The LRW-32-AES specification I used can be found at:
http://grouper.ieee.org/groups/1619/email/pdf00017.pdf



It implements the optimization specified as optional in the
specification, and in addition it uses optimized multiplication
routines from gf128mul.c.

Since gf128mul.[ch] is not tested on bigendian, this cipher mode
may currently fail badly on bigendian machines.
Signed-off-by: default avatarRik Snel <rsnel@cube.dyndns.org>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      64470f1b
    • Rik Snel's avatar
      [CRYPTO] lib: table driven multiplications in GF(2^128) · c494e070
      Rik Snel authored 
      A lot of cypher modes need multiplications in GF(2^128). LRW, ABL, GCM...
I use functions from this library in my LRW implementation and I will
also use them in my ABL (Arbitrary Block Length, an unencumbered (correct
me if I am wrong, wide block cipher mode).

Elements of GF(2^128) must be presented as u128 *, it encourages automatic
and proper alignment.

The library contains support for two different representations of GF(2^128),
see the comment in gf128mul.h. There different levels of optimization
(memory/speed tradeoff).

The code is based on work by Dr Brian Gladman. Notable changes:
- deletion of two optimization modes
- change from u32 to u64 for faster handling on 64bit machines
- support for 'bbe' representation in addition to the, already implemented,
  'lle' representation.
- move 'inline void' functions from header to 'static void' in the
  source file
- update to use the linux coding style conventions

The original can be found at:
http...
      c494e070
    • Kazunori MIYAZAWA's avatar
      [CRYPTO] xcbc: New algorithm · 333b0d7e
      Kazunori MIYAZAWA authored 
      
This is core code of XCBC.

XCBC is an algorithm that forms a MAC algorithm out of a cipher algorithm.
For example, AES-XCBC-MAC is a MAC algorithm based on the AES cipher
algorithm.
Signed-off-by: default avatarKazunori MIYAZAWA <miyazawa@linux-ipv6.org>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      333b0d7e
  23. 21 Sep, 2006 1 commit
    • Herbert Xu's avatar
      [CRYPTO] digest: Added user API for new hash type · 055bcee3
      Herbert Xu authored 
      
The existing digest user interface is inadequate for support asynchronous
operations.  For one it doesn't return a value to indicate success or
failure, nor does it take a per-operation descriptor which is essential
for the issuing of requests while other requests are still outstanding.

This patch is the first in a series of steps to remodel the interface
for asynchronous operations.

For the ease of transition the new interface will be known as "hash"
while the old one will remain as "digest".

This patch also changes sg_next to allow chaining.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      055bcee3
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7