Hi,
I have no longer the time to push for the cryptodev openssl patches.
If there is someone willing to take over, the initial pull request is
at:
https://github.com/openssl/openssl/pull/191
regards,
Nikos
___
Cryptodev-linux-devel mailing list
Cryptod
On Thu, May 28, 2015 at 12:06 PM, Gordan Bobic wrote:
>> Does that mean it is not a 0-copy related problem?
> In fact, I can confirm the problem is not at all related to mv_cesa.
> I just unloaded the mv_cesa driver which means that with cryptodev
> it will be the kernel doing the AES using the ge
On Mon, Feb 23, 2015 at 6:27 AM, Apoorva Bhatia
wrote:
> Hi,
>
> Actually I have been working on iMX6 processor (Sabre Lite board) which
> has CAAM which is the hardware accelerator. Now I need to load openssl and
> make it use CAAM. To do the same, I have first loaded a loadable module of
> cryp
On Sat, 2015-02-07 at 23:01 +0100, Phil Sutter wrote:
> - Fixed 'make dist', replacing most of the manual work in it with a
> simple call to 'git archive' while doing so.
> - Incremented Makefile's VERSION variable.
> - Tagged master with my own signature.
> - Used 'make dist' to create a new tar
On Fri, 2015-01-09 at 23:22 +0530, sri sowj wrote:
> HI Phil ,
> Thanks for the support and time,really appreciate it.
> Great to have suggestion on the issue,but still not clear with respect
> following.
> #1: "" There is /usr/include/crypto/cryptodev.h and it matches the
> cryptodev-linux install
On Tue, 2014-08-19 at 00:43 +0200, Phil Sutter wrote:
> > The patch doesn't show up on the git repository. Let me know if you've
> > just missed the push or are still reviewing so I can help you with it.
>
> But it is there. Maybe you pull from Nikos' repository? The 'official'
> upstream has mov
On Mon, 2014-08-11 at 10:09 +0300, Cristian Stoica wrote:
> >> I've tested this patch with AES-CBC-HMAC-SHA1 using the tls module that
> >> I've sent recently on Linux mailing list. That module needs rework for
> >> Lucky 13 and is a software alternative to the caam driver that does the
> >> same
On Wed, 2014-08-06 at 14:23 +0300, Cristian Stoica wrote:
> Hi Nikos,
>
> On 06.08.2014 13:58, Nikos Mavrogiannopoulos wrote:
> > On Fri, May 30, 2014 at 12:59 PM, Cristian Stoica
> > wrote:
> >> - block and stream ciphers have their keys copied from userspace
>
On Fri, May 30, 2014 at 12:59 PM, Cristian Stoica
wrote:
> - block and stream ciphers have their keys copied from userspace
> just like before
> - for aead composite ciphers, the cipher and hmac keys are
> combined into a single key
Hello Christian,
Do you have some test case on that? Which
On Tue, Jul 22, 2014 at 11:16 AM, cristian.sto...@freescale.com
wrote:
> Hi guys,
> Let me know what you think about this patch. Short of the TLS dst_len
> rounding fix, it should be just a refactoring.
> Replacing CIOCAUTHCRYPT with another ioctl that takes dst_len is not such a
> good idea in
On Tue, Jul 1, 2014 at 10:48 AM, cristian.sto...@freescale.com
wrote:
> Hi Phil,
>> This means we write more data into the userspace-supplied buffer than
>> requested without noticing it. Although this might be correct in regards
>> of the cipher mode's requirements, we could corrupt userspace mem
On Tue, Jun 24, 2014 at 6:29 PM, Joel Fernandes wrote:
I'm using OpenSSL 1.0.1g with cryptodev-linux v1.6 loaded, when I run
the following:
>>> Do you use the cryptodev.c from the openssl project or the one
>>> included in cryptodev-linux? The shipped cryptodev.c in openssl had
>>> some
On Tue, Jun 24, 2014 at 5:14 AM, Joel Fernandes wrote:
> Hi,
> I'm not able to even download a file from https with cryptodev loaded.
>
> I'm using OpenSSL 1.0.1g with cryptodev-linux v1.6 loaded, when I run
> the following:
Do you use the cryptodev.c from the openssl project or the one
included
On Tue, Apr 15, 2014 at 11:23 AM, Dien Nguyen
wrote:
> The ICV failed because the scatterlist dst_sg is created with shorter length
> than required (should be caop->len +
> cryptodev_cipher_get_tag_size(&ses_ptr->cdata)).
Hello Dien,
Your analysis seem correct.
> A possible fix is to change
>
Hello,
I no longer have time to work on cryptodev-linux, and I'd like to thank
Phil Sutter for taking over the maintenance of the project. Success Phil!
regards,
Nikos
___
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gn
On Thu, 2013-12-12 at 18:10 +0200, Horia Geanta wrote:
> From: Cristian Stoica
>
> Requires TLS patches on cryptodev and TLS algorithm support in Linux
> kernel driver.
Hello Horia,
This patch shouldn't be added before cryptodev-linux adds some
protection against the Lucky13 type of attacks (th
On Thu, Dec 12, 2013 at 3:35 PM, Horia Geantă
wrote:
>> Hello,
>> This does not compile. You seem to use dst_len that isn't there in the
>> definitions of these structures.
> Sorry for that. There are a few more patches that need to be upstreamed.
> We internally modified the interface (struct
On Mon, 2013-12-09 at 19:41 +0200, Horia Geanta wrote:
> Needed for 64b kernel with 32b user space.
>
> Signed-off-by: Horia Geanta
> Reviewed-by: Mircea Pop
> Reviewed-by: Cristian Stoica
> Tested-by: Cristian Stoica
> ---
> authenc.c | 80
> +
On Fri, Dec 6, 2013 at 1:22 PM, Cristian Stoica
wrote:
> Hi Nikos,
>
> Just for reference, I've found a possible workaround for this problem.
> I could not reproduce the issue after I disabled in openssl eng_cryptodev.c
> all the algorithms and digests that were not available in the kernel.
> Pro
On Wed, 2013-12-04 at 17:31 +0100, Nikos Mavrogiannopoulos wrote:
> > So the only way to still use the zero-copy would be to fix openvpn?
> I guess so, unless the driver can work-around that alignment
> limitation. This may be quite an issue with other software too. For
> exampl
On Wed, Dec 4, 2013 at 5:59 PM, Cristian Stoica
wrote:
>> That's pretty strange as the issue is a crash on crypto_alloc_ahash()
>> which only includes the hash name parameter. If you protect the
>> cryptodev_cipher_init and cryptodev_hash_init with a mutex does it help?
> []
> I've guarded both cr
On Wed, Dec 4, 2013 at 11:21 AM, Karl Hiramoto wrote:
>> Could you then try modifying main.c, at crypto_run() to set the
>> COP_FLAG_NO_ZC if there is no 16-byte alignment? If that fixes the
>> issue, we should see how we can handle it depending on the driver.
> Yes, it does fix it. However perf
On Wed, 2013-12-04 at 10:20 +0100, Karl Hiramoto wrote:
> I think the issue might be the memory alignment, the HW wants 16 byte
> alignment.
>
> I do echo 9 > /proc/sys/ioctl/cryptodev_verbosity
>
> and start to see messages liks:
> [ 1102.87] cryptodev: openvpn[693] (get_userbuf:157): care
On Tue, 2013-12-03 at 09:41 +, Cristian Stoica wrote:
> Hi Nikos,
>
> I'm investigating a kernel crash that happens fairly quickly when multiple
> cryptodev sessions are opened in parallel.
> I've tested the issue both on intel and power_pc and the traces are similar.
> There is no support f
On Mon, 2013-12-02 at 16:33 +0100, Karl Hiramoto wrote:
> Hi all,
>
> I'm using openssl 1.0.1e and OpenVPN 2.3.2
>
> I'm using the cryptodev-linux/extras/eng_cryptodev.c with openssl
[...]
> Mon Dec 2 14:56:26 2013 us=282785 test1/10.64.1.3:64764 PID_ERR large
> diff [1693821396] [SSL-0]
> [
On Wed, 2013-11-27 at 18:44 +0200, Cristian Stoica wrote:
> The net result is the same and it makes more clear some problems with
> freeing this memory (addressed in a later patch)
>
> Signed-off-by: Cristian Stoica
Applied all 4 of them.
regards,
Nikos
__
On 11/01/2013 09:14 AM, Cristian Stoica wrote:
> Hi Nikos,
>
>> Have you tested the interface with a non-stream AEAD cipher?
> []
>
> Yes, I have some pending patches that target aead ciphers. Specifically it's
> a cipher that does TLS-AES-SHA1 as a single crypto operation - somewhat
> simila
On 10/31/2013 10:56 AM, Cristian Stoica wrote:
> Signed-off-by: Cristian Stoica
> ---
> authenc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Hello Cristian,
Have you tested the interface with a non-stream AEAD cipher?
regards,
Nikos
On 10/22/2013 11:51 AM, Cristian Stoica wrote:
> kmalloc + memset(0) can be replaced with a single call to kzalloc for
> the same results
Both applied. Thanks.
___
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gna.org/
Applied. Thank you.
On 09/18/2013 01:09 PM, Cristian Stoica wrote:
> Signed-off-by: Cristian Stoica
> ---
> ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ioctl.c b/ioctl.c
> index ae95cf5..9bd968d 100644
> --- a/ioctl.c
> +++ b/ioctl.c
> @@ -260,7 +260,7 @@ cr
On 09/16/2013 10:18 AM, Stoica Cristian-B18196 wrote:
>> AFAIK, AEAD is supported by a few crypto engines and their drivers.
>> So simply using the AEAD interface of cryptodev-linux should
>> suffice if appropriate hardware is present.
> []
>
> Authenticated encryption *dedicated schemes* (algori
On Thu, 12 Sep 2013 13:42:05 +
Stoica Cristian-B18196 wrote:
> Hi Nikos,
>
> I'm looking at a possibility to add support for composite algorithms
> in cryptodev. Basically this means support for algorithms that do for
> example AES-CBC and HMAC(SHA1) in one call on platforms that support
> i
On Mon, Aug 12, 2013 at 2:45 PM, Nikolaos Tsakalakis
wrote:
> In case it is necessary for the cryptodev module to be built-in on the
> kernel, there is an issue on how to change the cryptodev_verbosity variable
> (which indicates the trace depth).
> One solution could be to add it on the sysctl ta
Applied, thanks.
On 07/01/2013 03:41 PM, Cristian Stoica wrote:
> Signed-off-by: Cristian Stoica
> ---
> crypto/cryptodev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/cryptodev.h b/crypto/cryptodev.h
> index a2f11b1..7fb9c7d 100644
> --- a/crypto/cryptodev.h
On 06/27/2013 03:42 PM, Cristian Stoica wrote:
> [PATCH] allow user override for kernel and installation directory
>
> Hi Nikos,
>
> I've been working with cryptodev for several days and found this patch to be
> useful for me.
> It's just a convenience patch and it may be useful for others, too
On 06/26/2013 07:18 PM, bassamtabbara wrote:
> In our case the old code prior to this change has already been
> released (in firmware) as well. Is there an easy way to get the
> version of cryptodev so that we can make the use of SHA_256
> conditional on the version?
Of course. You can modify th
On 06/26/2013 10:43 AM, bassamtabbara wrote:
> this line broke our code that relies on CRYPTO_SHA2_256 having a value of 103
> in the enum. It also breaks compatibility with older versions of this
> library. Can CRYPTO_SHA2_224 go at the bottom of the enum instead?
> https://github.com/nmav/cryp
On Sat, May 25, 2013 at 8:58 PM, Anthony Foiani
wrote:
> Nikos, JT --
> On Sat, May 25, 2013 at 12:40 PM, Nikos Mavrogiannopoulos
> wrote:
>> I was under the impression the latest openssl included quite a decent
>> eng_cryptodev.c, but as I understand from your mail
On 05/24/2013 06:19 AM, JT Olds wrote:
>> Hello,
>> It seems that the /dev/crypto device in that system is from an older
>> cryptodev driver. You may want to unload the old module and load the new
>> one.
> This is release 1.6 that I built and deployed. Is there something newer?
No. However you
On 05/21/2013 10:54 PM, JT Olds wrote:
> Hey all,
>
> I have a Marvell ARM device (kirkwood/mv_cesa) running Debian Wheezy (so,
> OpenSSL 1.0.1e) with a Linux 3.8.6 kernel. I am trying to get cryptodev to
> work.
> First off, cryptodev's "make check" fails the following tests:
> ./cipher-aead-srt
On Tue, May 21, 2013 at 11:07 AM, Nikolaos Tsakalakis
wrote:
> No, I am just talking about debugging cryptodev
Then, to answer your initial question, I don't know if it would be
necessary, but it looks quite useful. As I'm unfamiliar with the
traces I cannot make any informed suggestions but
On Fri, May 17, 2013 at 12:03 PM, Nikolaos Tsakalakis
wrote:
> Hello all,
> I am considering to develop several traces in kernel-cryptodev patch for
> debugging issues. Do you think that this is necessary? Are there any tips
> you think I should be based (e.g. buggy field, common errors)?
Hello N
On Tue, Apr 30, 2013 at 6:51 AM, Anthony Foiani
wrote:
> SHA1 -- about 2.5x slower using cryptodev than native CPU
> instructions. Is that expected?
In some (many?) systems the CPU can handle hashes much faster than the
crypto chip. Note also that in that time includes the context switch
from u
On Thu, Apr 4, 2013 at 2:14 PM, Costas Stasimos wrote:
>
> Hello!
>
> I'm currently using the cryptodev and i'm trying to evaluate the
> performance of some TLS handshakes.
> My tests are on port 443 (tomcat server is used)
> By observing the results. It seems that the cryptodev is slower that
> s
On 03/29/2013 10:12 AM, Joel A Fernandes wrote:
>> Hello,
>> The Linux-kernel maintainer rejected the /dev/crypto solution and has
>> added similar - but incompatible - functionality in the mainline kernel.
>> Check AF_ALG. There is comparison with it in cryptodev-linux pages.
> Thanks for your
On 03/29/2013 06:41 AM, Joel A Fernandes wrote:
> My questions are:
> (1) Why is the cryptodev-linux maintained separately outside of the kernel
> tree? Is there a plan to push it to the mainline kernel?
Hello,
The Linux-kernel maintainer rejected the /dev/crypto solution and has
added similar
Hello,
I've just released cryptodev-linux 1.6. The changelog since version 1.5
follow.
Version 1.6 (released 2013-03-20)
* Added modules_install target in Makefile
* Added SHA224. Patch by Yashpal Dutta.
* Asynchronous operations will not be scheduled if zero
copy is disabled.
* Asynchronous
On Tue, Mar 12, 2013 at 3:23 PM, Costas Stasimos wrote:
> Hello!
> I'm currently using the cryptodev framework with openssl-1.0.1e.
> By run the command
> we can see that the cryptodev is the active-chosen engine.
> So it seems that all the cryptographic load is directed automatically to
> /dev/cr
On 02/27/2013 01:45 AM, Zi Zhou wrote:
> I am new to cryptodev and HW acceleration. So my question is very
> basic. I have built cryptodev module and loaded to my kernel, the HW
> crypto driver is in development by other party, I don't quite know
> how the 2 glue together. Is there any extra logi
On 02/15/2013 04:22 PM, Dutta Yashpal-B05456 wrote:
> Hi Phil,
>
> This can break because copy_from/to_user() copies from the current user
> process (which should be obvious, since
> there's no way to tell it which user process to copy from).
>
> In a syscall invoked by your userspace process
On Fri, Feb 1, 2013 at 6:24 AM, Dutta Yashpal-B05456
wrote:
> Hi,
>
> In cryptodev, there are some scenarios where in/out parameters are allocated
> on stack. One of few such cases is
> as follows:
>
> During cryptodev_hash_init, the Mackey being passed to crypto_ahash_setkey
> is on stack and
Hello,
I've moved the source and the web pages of cryptodev-linux at github.
The new pages are at:
http://cryptodev-linux.org/
and the source code at:
https://github.com/nmav/cryptodev-linux/
regards,
Nikos
___
Cryptodev-linux-devel mailing list
Crypt
On 01/24/2013 11:22 PM, Yashpal Dutta wrote:
> 1) The keylen in cryptodev_dh_compute_key is already in bits. So, avoid
> multiplying
> it with 8 while passing it to cryptodev.
>
> 2) cryptodev_dh_compute_key must return size of secret generated as expected
> by openssl.
>
> Signed-off-by: Yash
On 01/24/2013 11:55 PM, Yashpal Dutta wrote:
> Signed-off-by: Yashpal Dutta
> ---
> crypto/cryptodev.h |2 ++
> extras/eng_cryptodev.c | 21 +
> ioctl.c|8
> 3 files changed, 31 insertions(+), 0 deletions(-)
Thanks. Applied.
On Mon, Jan 7, 2013 at 2:36 PM, Kees-Jan Hermans wrote:
> It is, however, a question surrounding some confusion I have wrt using
> cryptodev: on the internet (for example, here:
>
> http://wiki.ipfire.org/en/optimization/cryptodev
> ) I find references that cryptodev can do AES-256. In crypto/cryp
On 11/30/2012 11:33 AM, Nikolaos Tsakalakis wrote:
> Hello all,
>
> I have an issue concerning cryptodev and talitos use. I use kernel 2.6.32-13,
> however I use the talitos version of 2.6.35 backported. I have several times
> a crash like the one below.
[...]
>
> I attach the objdump. Having
On 11/28/2012 11:39 AM, Yashpal Dutta wrote:
> 1) Cryptodev-linux being a linux kernel module require a build target for
>module_install and not for install.
> 2) Some cross-compiler target need installation of module to different
> directory
> than host's module directory path. PREFIX allow
On 11/21/2012 08:58 AM, nick Rakar wrote:
> > Could you try removing those flags?
> Yes, i replace the flags with zeros and the compilation was successful.These
> flags appeared at definitions:
> static const EVP_MD cryptodev_sha1 static const EVP_MD cryptodev_sha256
> static const EVP_MD crypto
On 11/19/2012 03:04 PM, nick Rakar wrote:
>
> Hello!
> I download the sources cryptodev-linux-1.5 and according to the README file i
> replace the eng_cryptodev.c file of openssl (crypto/engine/) with the version
> available in the extras subdirectory and also i add the flags
> -DHAVE_CRYPTOD
On 11/03/2012 09:08 PM, Frediano Ziglio wrote:
> Hi, what I'm trying to do is to store a connection in another process
> to do connection pooling.
If by storing connection you mean to transfer a gnutls session from one
process to another, you cannot do it, either with cryptodev or without.
The
On 11/03/2012 03:22 PM, Frediano Ziglio wrote:
> Hi,
> I'm searching for a way to pass a TLS session between two programs
> under Unix. I can use unix sockets to send the file descriptor but I
> don't know how to request to GnuTLS crypto information (like algorithm
> used and key) in order to pa
On 09/24/2012 08:46 PM, Lluís Batlle i Rossell wrote:
>> There will be no much change. If you mv_cesa doesn't support sha1, it
>> may be faster to use the userspace implementation of sha1.
> I got it working. Simply, the mv_cesa wants a 'fallback'. Maybe for some
> shorter-than-usual-length block
On 09/23/2012 11:54 PM, Lluís Batlle i Rossell wrote:
>> Specifically, this 3.5.4 reports on dmesg:
>> MV-CESA:Fallback driver 'hmac(sha1)' could not be loaded!
>> MV-CESA:Fallback driver 'sha1' could not be loaded!
>>
>> This happens every time I run something doing sha1 in openssl. Let it be
>>
On 09/20/2012 04:55 PM, Tom St Denis wrote:
> I see that cryptodev supports AEAD mode with GCM but are there any plans to
> add AEAD support for generic cipher/hash modes? Some crypto hardware support
> these modes and it would be nice to have access to it via the userspace API.
The current AE
On Tue, Sep 4, 2012 at 11:59 PM, Sridhar Manickam wrote:
> Nikos,
> I was able to get the samples for STORE WRAP & STORE UNWRAP working. Thanks
> for your help. What is minimum Linux Kernel version that is needed to support
> the /dev/ncr ?
Most probably it would work from the 2.6, but the only
On 08/29/2012 11:05 PM, Sridhar Manickam wrote:
> Nikos,
>
> Thanks for your response. I have looked at the aes.c sample and have some
> follow up questions
> The executable aes runs fine even without me using the ncr-setkey to set the
> master key, so does that mean the data encryption key is
On 08/17/2012 06:45 PM, Sridhar Manickam wrote:
> Hi,
>
> My expertise with C on Linux is quiet rusty. What we were looking for
> is a mechanism to store a Master key in Linux which is strongly
> protected and I came across the crypto-dev project and thought using
> the /dev/ncr to store the mast
Hello,
I've just released cryptodev-linux 1.5. This is a bug fix release.
A brief changelog follows.
Version 1.5 (released 2012-08-04)
* Fixes in AEAD support. Patches by Jaren Johnston.
* Simplifications in memory locking. Patch by Phil Sutter.
* Allow empty plaintext and authenticated data
On 08/02/2012 12:51 AM, Jaren Johnston wrote:
> Hmm... that *was* the output from git format-patch... apparently mangled :-/
>
> Here it is as an attachment.
Applied, thank you!
___
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
ht
Thanks Jaren,
Could you send the patch attached, so I can apply it cleanly. Your
mailer breaks the format. It is better to use the output of git
format-patch.
regards,
Nikos
On 07/27/2012 07:50 PM, Jaren Johnston wrote:
>
>
> Output buffer doesn't hold tag on decrypt, so no need to account f
Applied!
On 07/16/2012 03:10 PM, Phil Sutter wrote:
>
> Signed-off-by: Phil Sutter
> ---
> authenc.c | 28 ++--
> cryptlib.c |2 +-
> cryptlib.h |2 +-
> cryptodev_int.h |2 +-
> ioctl.c |4 ++--
> lib/benchmark.c |8 ---
Applied thank you.
On 06/29/2012 12:09 AM, Jaren Johnston wrote:
> Hey,
>
>
>
> During yet more gcm testing, I ran into cases where I'd end up sitting on a
> trylock:
>
>
>
> ioctl.c:321: if (!mutex_trylock(&ses_ptr->sem)) {
>
> ioctl.c-322- dprintk(2, KE
On 06/15/2012 10:33 PM, Jaren Johnston wrote:
>> [Nikos Mavrogiannopoulos]
>>> btw, your description
>>> on the second patch in this mail doesn't really match the contents.
>>
>> [Jaren Johnston]
>> Wow... ok then. Neither one of those is what I
On 06/12/2012 08:11 PM, Jaren Johnston wrote:
>> [Jaren Johnston]
>>
>> Yes: Your original loop works fine -- except if I set
> DEFAULT_PREALLOC_PAGES
>> = 0. I don't personally need that case... I'd set DEFAULT_PREALLOC_PAGES
> = 1
>> just now during testing, to ensure page requests doubled nice
On Fri, Jun 15, 2012 at 1:56 PM, Phil Sutter wrote:
> I was rather referring to the #if 0 above, effectively deactivating the
> whole set of *_HMAC digests. :)
Ah, ok. I saw that the digest_init() function had:
sess->mackey = state->dummy_mac_key;
sess->mackeylen = digest_key_length(ctx->digest
On Fri, Jun 15, 2012 at 12:41 PM, Phil Sutter wrote:
> Hi,
> On Thu, Jun 14, 2012 at 04:38:03PM +0200, Nikos Mavrogiannopoulos wrote:
>> Which changes do you refer to? If I remember well this file is based
>> on the eng_cryptodev.c of 1.0.1.
> Particularly those:
>
>
On Thu, Jun 14, 2012 at 4:04 PM, Phil Sutter wrote:
> Hi,
> I am currently comparing eng_cryptodev.c in current cryptodev-linux git
> with the same file in openssl-1.0.0c, wondering about the differences.
> Why the commented out support for HMAC modes? I assume cryptodev-linux
> should still serve
On 06/09/2012 11:18 PM, Jaren Johnston wrote:
> Author: Jaren Johnston
> Date: Fri Jun 8 15:49:03 2012 -0700
>
>
>
> adjustment to adjust_sg_array
>
>
>
> Replaced the exponential requesting of memory w/ something more linear.
Why is that? Did you notice any issues with the
On 06/09/2012 10:42 PM, Jaren Johnston wrote:
> Hey there,
> I've recently been working on some GCM cases with empty PT and AAD. I don't
> know how useful they are in practice, but they're legit and show up in
> validation tests (e.g., FIPS).
Hello,
Indeed it is a useful addition. However you
On 05/17/2012 12:34 AM, Jaren Johnston wrote:
> Hi all,
>
> I enjoyed finding these while testing on a system where I'd forgotten to
> enable gcm in the kernel. I.e., these bugs are on error flows, and I
> wouldn't expect to encounter them normally.
Thank you Jaren. I've applied the fixes.
>
d add some fixes so "make
test" succeeds on openssl. Could you try this version of eng_cryptodev.c?
regards,
Nikos
/*
* Copyright (c) 2002 Bob Beck
* Copyright (c) 2002 Theo de Raadt
* Copyright (c) 2002 Markus Friedl
* Copyright (c) 2012 Nikos Mavrogiannopoulos
* All rights reserv
Hello,
I've just released cryptodev-linux 1.4. This release includes
a minor update. The changelog since 1.3 is:
Version 1.4 (released 2012-03-15)
* Correctly report hw accelerated ciphers.
regards,
Nikos
___
Cryptodev-linux-devel mailing list
Crypto
er wrote:
> Hi,
>
> On Wed, Feb 29, 2012 at 01:19:43PM +0100, Nikos Mavrogiannopoulos wrote:
>> On Tue, Feb 28, 2012 at 11:56 PM, Phil Sutter wrote:
>> > Another thing I just noticed, these commit-mails are somehow broken.
>> > E.g. backslashes are missing comple
Hello,
I've just released cryptodev-linux 1.3. This release includes
few minor updates. The changelog since 1.2 is:
Version 1.3 (released 2012-02-29)
* Return EBADMSG instead of ECANCELED on tag verification
failure in authenc modes.
* COP_FLAG_RESET can be combined with COP_FLAG_UPDATE for
eff
On Tue, Feb 28, 2012 at 11:56 PM, Phil Sutter wrote:
>> > - forgot to add openssl_wrapper.h
>> > - aligned second patch's subject line with the first one
>> Thank you Phil. I've just committed them!
> Great, thanks! I found this very useful for debugging problems with
> mv_cesa. Hard-coding diges
On 02/28/2012 06:27 PM, Phil Sutter wrote:
> From Phil Sutter # This line is ignored.
> From: Phil Sutter
> Subject: Fixup of my initial patch series
> In-Reply-To: 1330443633-12558-1-git-send-email-phil.sut...@viprinet.com
>
> - forgot to add openssl_wrapper.h
> - aligned second patch's subjec
On 02/24/2012 09:24 AM, Frank wrote:
> I'll try to find time to check platform-dependence by testing on a
> virtual x86 installation, and will contact the code submitters of
> eng_cryptodev.c in openssl more directly with the results.
It seems the openssl digests option was never tested with cr
Hello,
I've just released cryptodev-linux 1.2. This fixes an issue
with mv_cesa in ARM processors, adds COP_FLAG_RESET to allow
resetting the state of a hash or HMAC, and sets the flag
SIOP_FLAG_KERNEL_DRIVER_ONLY on systems that the kernel doesn't
support the CRYPTO_ALG_KERN_DRIVER_ONLY flag, usi
On 02/24/2012 08:55 AM, Frank wrote:
> The fix solves the problems with gnutls-cli --benchmark-tls when
> mv_cesa is loaded. Thanks! Note that the openssl problems (segfault
> with openssl s_server, nginx crashing when serving https) occur
> regardless of whether mv_cesa is loaded or not on my A
On 02/23/2012 07:48 PM, Phil Sutter wrote:
>> These are the specs: - On Marvell Kirkwood hardware - Running
>> Debian Wheezy (Linux kernel 3.2.0) - cryptodev-linux 1.0 - (Debian
>> version of) openssl 1.0.0g with cryptodev support (both tried
>> -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX
Hello,
I've just released cryptodev-linux 1.1. It adds
new features to the API. Part of this work was sponsored
by the OpenSSL foundation.
The changelog since 1.0 is:
Version 1.1 (released 2012-02-20)
* Fixed alignment issue in speed.c
* Defined HASH_MAX_LEN is cryptodev.h
* CIOCGSESSINFO ioc
On 02/19/2012 11:34 AM, Frank wrote:
>> Hello,
>> (note that the main mailing list is cryptodev-linux-devel@gna.org)
> I was first thinking about sending my report there, but then I read that
> bug-reports should be send to cryptodev-linux-com...@gna.org on the following
> page: http://home.gn
Hello,
(note that the main mailing list is cryptodev-linux-devel@gna.org)
What is the output you get from "make check" in the cryptodev
distribution? Could you provide a backtrace of the gnutls-cli segfault?
regards,
Nikos
PS. About the openssl speed, you need to use -evp mode to enable other
e
Hello,
In the aead branch of cryptodev-linux repository [0], I've added a
new interface to access authenticated encryption ciphersuites (aead).
This includes combinations of cipher/mac for TLS and SRTP. This allows
combining the operation of encryption and mac on a single system call.
This is achi
On 09/01/2011 05:32 PM, David Miller wrote:
From: Nikos Mavrogiannopoulos
Date: Thu, 1 Sep 2011 17:06:06 +0200
It would be interesting to have a partial kernel-space TLS
implementation but I don't know whether such a thing could ever make
it to kernel.
Herbert and I have discussed
On Thu, Sep 1, 2011 at 4:59 PM, Herbert Xu wrote:
>> latency, maybe(?) high throughput or so). Thus, I designed this
>> benchmark with a use-case in mind, i.e., a TLS or DTLS tunnel
>> executing in a system with such an accelerator. There might be other
>> benchmarks with other use cases in mind,
On Thu, Sep 1, 2011 at 4:14 PM, Herbert Xu wrote:
> Are you maxing out your submission CPU? If not then you're testing
> the latency of the interface, as opposed to the throughput.
I think it is obvious that a benchmark of throughput measures
throughput. If however, you think that AF_ALG is in d
On 09/01/2011 08:43 AM, Herbert Xu wrote:
On Thu, Sep 01, 2011 at 08:26:07AM +0200, Nikos Mavrogiannopoulos wrote:
Actually this is the reason of the ecb(cipher-null) comparison. To
emulate the case of a hardware offload device. I tried to make that
clear in the text, but may not be. If you
On 09/01/2011 04:15 AM, Herbert Xu wrote:
Nikos Mavrogiannopoulos wrote:
Given my benchmarks have no issues, it is not apparent to me why one
should use AF_ALG instead of cryptodev. I do not know though why AF_ALG
performs so poor. I'd speculate by blaming it on the usage of the socke
On 08/28/2011 10:35 PM, David Miller wrote:
The benchmark idea was to test the speed of initialization, encryption
and deinitiation, as well as the encryption speed alone. These are the
most common use cases of the frameworks (i.e. how they would be used
by a cryptographic library).
Be sure to
1 - 100 of 148 matches
Mail list logo
