summaryrefslogtreecommitdiffstats
path: root/sys/crypto
Commit message (Collapse)AuthorAgeFilesLines
* Initialize T1 to silent gcc warning.kevlo2006-10-221-1/+1
| | | | Approved by: cognet
* Less magic.pjd2006-09-151-2/+3
| | | | MFC after: 3 days
* GCC 3.4.6 gets confused on this file and produces bogus warning.kan2006-08-261-1/+1
| | | | Shut it up.
* Remove trailing spaces.pjd2006-07-281-1/+1
|
* Use existing roundup2() macro.pjd2006-07-281-1/+1
| | | | Suggested by: njl
* Remove redundant check committed by accident.pjd2006-07-251-2/+0
|
* Avoid memory allocations when the given address is already 16 bytes aligned.pjd2006-07-251-6/+51
| | | | | | | | | | | | | | Such an address can be used directly in padlock's AES. This improves speed of geli(8) significantly: # sysctl kern.geom.zero.clear=0 # geli onetime -s 4096 gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=1000 Before: 113MB/s After: 203MB/s BTW. If sector size is set to 128kB, I can read at 276MB/s :)
* Modify PADLOCK_ALIGN() macro, so when the given address is already 16 bytespjd2006-07-251-1/+1
| | | | aligned, it will be used directly, not 'address + 16'.
* Style fixes.pjd2006-07-254-10/+10
|
* Implement support for HMAC/SHA1 and HMAC/SHA256 acceleration found inpjd2006-07-224-335/+766
| | | | | | | | | | | new VIA CPUs. For older CPUs HMAC/SHA1 and HMAC/SHA256 (and others) will still be done in software. Move symmetric cryptography (currently only AES-CBC 128/192/256) to padlock_cipher.c file. Move HMAC cryptography to padlock_hash.c file. Hardware from: Centaur Technologies
* Correct few bzero()s.pjd2006-07-221-3/+3
| | | | MFC after: 3 days
* Set ses_ictx and ses_octx to NULL after freeing them, so we won't freepjd2006-07-221-0/+2
| | | | | | | | | them twice. This is possible for example in situation when session is used in authentication context, then freed and then used in encryption context and freed - in encryption context ses_ictx and ses_octx are not touched at newsession time, but padlock_freesession could still try to free them when they are not NULL.
* Use the already stored VIA RNG probe informationmr2006-07-131-16/+5
| | | | | | | | instead of probing again. Adjust style(9) somewhat in probe.c Reviewed by: pjd MFC after: 1 week
* Fix gratuitous compiler warning.pjd2006-06-081-1/+2
| | | | Reported by: Rong-en Fan <grafan@gmail.com>
* - Pretend to accelerate various HMAC algorithms, so padlock(4) can be usedpjd2006-06-051-91/+266
| | | | | | | | with fast_ipsec(4) and geli(8) authentication (comming soon). If consumer requests only for HMAC algorithm (without encryption), return EINVAL. - Add support for the CRD_F_KEY_EXPLICIT flag, for both encryption and authentication.
* padlock(4) doesn't support explicitly provided keys yet.pjd2006-04-201-0/+4
| | | | Return an error instead of encrypting/decrypting data with a wrong key.
* On padlock initialization, allocate memory with M_WAITOK.pjd2006-04-121-5/+1
|
* Add VIA/ACE "PadLock" support as a crypto(9) driver.pjd2005-08-181-0/+504
| | | | | | HW donated by: Mike Tancsa <mike@sentex.net> Most of the code obtained from: OpenBSD MFC after: 3 days
* Assert proper key size also in userland by defining KASSERT in !_KERNEL case.pjd2005-08-171-2/+2
|
* Unbreak the world build (in sbin/gbde). This file is used by bothcperciva2005-08-171-0/+2
| | | | | | | kernel and world, so KASSERT() needs to be wrapped within an #ifdef _KERNEL / #endif pair. Reported by: krion, tinderbox
* Check key size for rijndael, as invalid key size can lead to kernel panic.pjd2005-08-161-0/+2
| | | | | | | | | It checked other algorithms against this bug and it seems they aren't affected. Reported by: Mike Tancsa <mike@sentex.net> PR: i386/84860 Reviewed by: phk, cperciva(x2)
* gbde(8) is also rejndael user.ume2005-03-111-2/+0
| | | | Reported by: phk
* just use crypto/rijndael, and nuke opencrypto/rindael.[ch].ume2005-03-111-5/+0
| | | | | | the two became almost identical since latest KAME merge. Discussed with: sam
* integrate rijndael-alg-fst.h into rijndael.h.ume2005-03-115-44/+14
|
* stop including rijndael-api-fst.h from rijndael.h.ume2005-03-111-1/+0
| | | | this is required to integrate opencrypto into crypto.
* sys/crypto/md5.[ch] is used from nowhere. So, just nuke them.ume2005-03-112-382/+0
|
* refer opencrypto/cast.h directly.ume2005-03-111-17/+0
|
* use cast128 in opencrypto to nuke duplicate code.ume2005-03-103-811/+9
|
* Start the dreaded NOFOO -> NO_FOO conversion.ru2004-12-211-1/+1
| | | | OK'ed by: core
* Initiate deorbit burn sequence for 80386 support in FreeBSD: Removejhb2004-11-161-1/+1
| | | | 80386 (I386_CPU) support from the kernel.
* For variables that are only checked with defined(), don't provideru2004-10-241-1/+1
| | | | any fake value.
* Use __FBSDID().obrien2004-06-143-3/+13
|
* Fix a reentrancy issue in md5_calc().des2004-01-271-4/+1
|
* avoid module name conflict with opencrypto/rijndael.c.ume2003-11-121-0/+0
| | | | Reported by: tinderbox
* cleanup rijndael API.ume2003-11-112-1/+107
| | | | | | | since there are naming conflicts with opencrypto, #define was added to rename functions intend to avoid conflicts. Obtained from: KAME
* rijndael-alg-fst.[ch]:ume2003-11-104-1634/+1332
| | | | | | | | | | | - redo updating. rijndael-api-fst.[ch]: - switch to use new low level rijndael api. - stop using u8, u16 and u32. - space cleanup. Tested by: gbde(8) and phk's test program
* Add a testcase which validates that the same buffer can be passed tophk2003-10-192-0/+87
| | | | | | | | | | rijndael_blockDecrypt() as both input and output. This property is important because inside rijndael we can get away with allocating just a 16 byte "work" buffer on the stack (which is very cheap), whereas the calling code would need to allocate the full sized buffer, and in all likelyhood would have to do so with an expensive malloc(9).
* - revert to old rijndael code. new rijndael code broke gbde.ume2003-10-194-1424/+1702
| | | | | - since aes-xcbc-mac and aes-ctr require functions in new rijndael code, aes-xcbc-mac and aes-ctr are disabled for now.
* Fix alignment problem on 64 bit arch.ume2003-10-141-0/+49
| | | | | | | I only tested if it doesn't break anything on i368. Since I have no 64 bit machine, I cannot test it, actually. Reported by: jmallett
* use BF_ecb_encrypt().ume2003-10-132-2/+88
| | | | Obtained from: KAME
* simplify and update rijndael code.ume2003-10-126-1737/+1407
| | | | Obtained from: KAME
* use opencrypto for RMD160.ume2003-10-122-409/+0
| | | | Requested by: sam
* drop useless define.ume2003-10-121-3/+0
|
* use bswap32() for big endian arch.ume2003-10-121-1/+1
| | | | Reported by: tinderbox via kris
* RIPEMD160 supportume2003-10-122-0/+412
| | | | Obtained from: KAME
* switch cast128 implementation to implementation by Steve Reid;ume2003-10-104-1008/+790
| | | | | | smaller footprint. Obtained from: KAME
* one more opossite conditiion.ume2003-09-181-1/+1
| | | | Reported by: "lg" <zevlg@yandex.ru>
* condition of padLen check was opposite.ume2003-09-171-1/+1
| | | | | Reported by: "lg" <zevlg@yandex.ru> Reviewed by: Lev Walkin <vlm@netli.com>
* Correctly bzero the entire context, not just the first sizeof(void *) bytes.phk2003-09-081-6/+6
| | | | Found by: Juergen Buchmueller <pullmoll@stop1984.com>
* Use __FBSDID().obrien2003-06-109-14/+30
|
OpenPOWER on IntegriCloud