On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller wrote:
> And finally, you have a coding error that is very very common but fatal when
> reading from /dev/random: you do not account for short reads which implies
> that your loop continues even in the case of short reads.
>
> Fix your code with som
On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller wrote:
>> Personally, I don't really use /dev/random, nor would I recommend it
>> for most application programmers. At this point, getrandom(2) really
>> is the preferred interface unless you have some very specialized
>> needs.
> I fully agree. Bu
On Tue, May 3, 2016 at 4:48 PM, wrote:
> On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote:
>> I believe their main concern is that they want to protect applications
>> which do not check error codes of system calls, when running on a
>> kernel w
On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o wrote:
> On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:
>> That's far from a solution and I wouldn't recommend to anyone doing
>> that. We cannot expect each and every program to do glibc
On Mon, Apr 25, 2016 at 10:02 AM, Stephan Mueller wrote:
>> > One more item to consider: If you do not want to change to use
>> > getrandom(2), the LRNG provides you with another means.
>> The main problem is not about willing to switch to getrandom() or not,
>> but finding any system where getran
On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller wrote:
>> > ... DRBG is “minimally” seeded with 112^6 bits of entropy.
>> > This is commonly achieved even before user space is initiated.
>>
>> Unfortunately one of the issues of the /dev/urandom interface is the
>> fact that it may start providing
On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller wrote:
> Hi Herbert, Ted,
>
> The venerable Linux /dev/random served users of cryptographic mechanisms well
> for a long time. Its behavior is well understood to deliver entropic data. In
> the last years, however, the Linux /dev/random showed sign
On Thu, Apr 14, 2016 at 12:46 AM, Tadeusz Struk wrote:
> Hi Fridolin,
> On 04/12/2016 04:13 AM, Fridolin Pokorny wrote:
>> we were experimenting with this. We have a prove of concept of a kernel
>> TLS type socket, so called AF_KTLS, which is based on Dave Watson's
>> RFC5288 patch. It handles bot
On Mon, Feb 23, 2015 at 9:18 AM, Stephan Mueller wrote:
>> one more thing while compiling openssl with above mentioned changes I
>> faced compilation issues in linux ,Please can you also let me know
>> whether there are per-requisites like any dependent libraries or
>> installing cryptodev-linux o
On Mon, Feb 23, 2015 at 5:06 AM, sri sowj wrote:
> Hi Nikos,
>
> Please can you let me know my understanding regarding openssl and
> crypto are correct?
> I have mentioned my understanding in my earlier posts,but let me
> mention it here again.
> I want to interact with Crypto Hardware from user s
On Sun, 2015-02-22 at 16:04 +0100, Stephan Mueller wrote:
> Am Sonntag, 22. Februar 2015, 18:32:34 schrieb sri sowj:
>
> Hi sri,
>
> > Hi Stephen,
> >
> > It was a great information with respective PF_ALG , I have explored a
> > bit on openssl and algorithms prospect , Please let me know if
> >
On Mon, 2014-09-15 at 20:40 -0400, Sandy Harris wrote:
> I have some experimental code to replace parts of random.c It is not
> finished but far enough along to seek comment. It does compile with
> either gcc or clang, run and produce reasonable-looking results but is
> not well-tested. splint(1)
On 09/27/2013 12:58 PM, Horia Geantă wrote:
> Thanks for the tip.
> I took a look at BSD - AFAICT there is no SW implementation and crypto
> engine drivers handle only the first two operations (MOD_EXP).
>
> My main concern now is the asymmetric ciphers API, that would eventually
> allow implemen
On 09/23/2013 02:31 PM, Horia Geantă wrote:
> Hi,
>
> CAAM crypto engine (drivers/crypto/caam/*) is capable of asymmetric
> operations, like: modular exponentiation, RSA
> sign/verify/encrypt/decrypt, (EC)DSA sign etc.
> I would appreciate some design guidelines on how to harness these
> capabilit
On 02/22/2012 02:03 PM, Frank wrote:
> Hi,
>
> After doing some trials with hardware crypto offloading through usermode
> interfaces (af_alg and cryptodev) to Marvell CESA accelerated ciphers and
> hash functions with the 3.2.4 kernel's mv_cesa in Debian Wheezy on a Marvell
> Kirkwood system,
This patch is the same as the previous but without the inline function.
regards,
Nikos
>From 1562727aab0e2fcce87e22a73abe6ea1c7c8975f Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Tue, 1 Nov 2011 13:39:56 +0100
Subject: [PATCH] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag.
The ad
On Fri, Jan 6, 2012 at 10:12 AM, Herbert Xu
wrote:
>> How the flag is exported by cryptodev-linux:
>> http://repo.or.cz/w/cryptodev-linux.git/blob/aead:/ioctl.c#l716
> Actually I was looking for code that uses crypto_tfm_alg_flags
> function.
The code above will use it once it is accepted. Now i
On Fri, Jan 6, 2012 at 9:28 AM, Herbert Xu wrote:
>> I needed this function in order to access the new flag without
>> relying on the structure format. The available crypto_tfm_alg_type()
>> would apply a mask and remove it, thus I added this function.
> Can you show me some example code so I can
On 01/06/2012 02:37 AM, Herbert Xu wrote:
> Nikos Mavrogiannopoulos wrote:
>> The added CRYPTO_ALG_KERN_DRIVER_ONLY indicates whether a cipher
>> is only available via a kernel driver. If the cipher implementation
>> might be available by using an instruction set or by porti
and other possible flags.
Signed-off-by: Nikos Mavrogiannopoulos
---
drivers/crypto/caam/caamalg.c |3 +-
drivers/crypto/geode-aes.c|6 +++-
drivers/crypto/hifn_795x.c|3 +-
drivers/crypto/ixp4xx_crypto.c|2 +
drivers/crypto/mv_cesa.c | 12
On 12/12/2011 09:43 PM, Kim Phillips wrote:
> This appears to be based on an older version of the current master
> of Herbert's cryptodev tree on github [1] - it's missing the hmac
> algorithms introduced in commit 79b3a41 "crypto: talitos - add hmac
> algorithms", and a caam entry is missing (it
and other possible flags.
Signed-off-by: Nikos Mavrogiannopoulos
---
drivers/crypto/caam/caamalg.c |3 +-
drivers/crypto/geode-aes.c|6 +++-
drivers/crypto/hifn_795x.c|3 +-
drivers/crypto/ixp4xx_crypto.c|2 +
drivers/crypto/mv_cesa.c | 12
The added CRYPTO_ALG_KERN_DRIVER_ONLY flag indicates whether a cipher
is only available via a kernel driver. If the cipher implementation
might be available by using an instruction set or by porting the
kernel code, then it must not be set.
Signed-off-by: Nikos Mavrogiannopoulos
---
drivers
On 11/01/2011 01:59 PM, Jamie Iles wrote:
> Hi Nikos,
>
> On Tue, Nov 01, 2011 at 01:43:26PM +0100, Nikos Mavrogiannopoulos wrote:
[...]
>> I suppose that no answer means there is no way. In that case would you
>> consider this or a similar patch to indicate whether a
On 10/28/2011 06:24 PM, Nikos Mavrogiannopoulos wrote:
>>> I can imagine, an alternative approach and perhaps better
>>> approach would be to measure the speed of the kernel provided
>>> algorithm against a software implementation, but there are many
>>> ot
On 10/21/2011 03:23 PM, Herbert Xu wrote:
> Matthias-Christian Ott wrote:
>> I did some experiments with af_alg and noticed that to be really
>> useful, it should indicate whether a certain algorithm is hardware
>> accelerated. I guess this has to be inferred by the priority of the
>> algorithm co
On 09/07/2011 10:02 PM, Steve Grubb wrote:
When a system is underattack, do you really want to be using a PRNG
for anything like seeding openssl? Because a PRNG is what urandom
degrades into when its attacked.
Using a PRNG is not a problem. Making sure it is well seeded and no
input from the a
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
Hello,
I've compared the cryptodev [0] and AF_ALG interfaces in terms of
performance [1]. I've put the results, as well as the benchmarks used
in: http://home.gna.org/cryptodev-linux/comparison.html
The benchmark idea was to test the speed of initialization, encryption
and deinitiation, as well
On Wed, Aug 17, 2011 at 2:23 PM, Dmitry Kasatkin
wrote:
>> Was there a particular reason to select the GnuPG mpi lib? Why not
>> include gmp (the gnupg mpi lib is a very old fork of gmp), or some other
>> big number library?
> GNUPG MPI kernel port was available and has shown the best performance
On Mon, Aug 15, 2011 at 6:12 PM, Dmitry Kasatkin
wrote:
> On 11/08/11 20:20, Dmitry Kasatkin wrote:
>> From: Dmitry Kasatkin
>>
>> Adds the multi-precision-integer maths library which was originally taken
>> from GnuPG and ported to the kernel by (among others) David Howells.
>> This version is t
On Thu, Jan 13, 2011 at 8:19 AM, Dmitry Kasatkin
wrote:
> Hi,
> Does anybody know if there is a GPL implementation of RSA verification
> for the Linux kernel?
> I know DigSig, but is anything recent available?
In NCR [http://home.gna.org/cryptodev-linux/ncr.html] I've added RSA and DSA
using the
On Fri, Jan 7, 2011 at 2:04 PM, Neil Horman wrote:
>> Btw, it doesn't have to be about performance per se. Does this allow
>> people to use keys without actually _seeing_ those keys? Your example
>> implies that that is not the case, but that's actually one of the few
>> reasons to actually suppo
On Tue, Oct 19, 2010 at 3:44 PM, Herbert Xu
wrote:
> OK I've gone ahead and implemented the user-space API for hashes
> and ciphers.
> To recap this interface is designed to allow user-space programs
> to access hardware cryptographic accelerators that we have added
> to the kernel.
> The intended
On Tue, Sep 7, 2010 at 4:06 PM, Christoph Hellwig wrote:
>> This is what I am proposing for the Crypto API user-interface.
>
> Can you explain why we would ever want a userspace interface to it?
>
> doing crypto in kernel for userspace consumers sis simply insane.
> It's computational intensive co
On Tue, Sep 7, 2010 at 4:11 PM, Herbert Xu wrote:
>> > This is what I am proposing for the Crypto API user-interface.
>>
>> Can you explain why we would ever want a userspace interface to it?
>>
>> doing crypto in kernel for userspace consumers sis simply insane.
>> It's computational intensive c
On 09/06/2010 10:42 PM, Kyle Moffett wrote:
>>> The problem with the approach you're proposing is that we then have
>>> two entirely separate classes of keys. First we have the existing
>>> keyring class, which can be securely and revokably passed between
>>> different processes with limited righ
On 09/06/2010 08:00 PM, Kyle Moffett wrote:
>> The kernel keyring service is basically a system-wide data storage
>> service. /dev/crypto needs a quick way to refer to short-lived,
>> usually process-local, kernel-space data structures from
>> userspace.
> The problem with the approach you're pro
On 09/06/2010 02:17 PM, Herbert Xu wrote:
> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
>>
>> I can see almost no overlap between the two sets of requirements. Probably
>> the only common use case is handling session keys (e.g. keys used in a
>> kerberos ticket), which should
On 09/03/2010 11:18 AM, Herbert Xu wrote:
> I will be looking at this myself so please stay tuned and be ready
> to yell if you see that your requirements are not met.
On 08/20/2010 03:56 PM, Ted Ts'o wrote:
> So I'm bit at a list what's the whole point of this patch series.
> Could you explain th
2010/9/3 Herbert Xu :
>> * ioctl(NCRIO_SESSION_INIT) to allocate a crypto session (to encrypt,
>> decrypt, hash, sign, or verify signature), then
>> ioctl(NCRIO_SESSION_UPDATE) to act on chunks of data. Deallocate the
>> session, and optionally retrieve session results (e.g. hash or
>> si
Hello,
I was checking the crypto_xor() function and it is for some reason
limited to 32 bit integers. Why not make it depend on the architecture
by replacing the u32 with unsigned long? That way 64bit machines should
perform xor with less instructions...
Something like:
void crypto_xor(u8 *dst,
On Mon, Aug 23, 2010 at 10:09 AM, Arnd Bergmann wrote:
>> This is an alternative design. There quite some reasons against that,
>> such as the auditing features. For me the main reason was that there
>> was no way to make it as fast (zero-copy) as this design, for the
>> requirements we had (int
On 08/21/2010 07:08 PM, Arnd Bergmann wrote:
> On Friday 20 August 2010 10:45:43 Miloslav Trmač wrote:
>>
>> Major changes since the previous post:
>> * "struct nlattr"-based extensible attributes used for extensibility
>> of most operations, both for input and output attributes
> The API here lo
On 08/21/2010 03:09 PM, Kyle Moffett wrote:
>> This patch introduces the new user-space API, .
>>
>> Quick overview:
>>
>> * open("/dev/crypto") to get a FD, which acts as a namespace for key and
>> session identifiers.
>>
>> * ioctl(NCRIO_KEY_INIT) to allocate a key object; then generate the key
2010/8/20 Stefan Richter :
>> +struct ncr_session_input_data {
>> + const void __user *data;
>> + __kernel_size_t data_size;
>> +};
>> +
>> +};
> Why not using fixed-size fit-all members?
> struct ncr_session_input_data {
> __u64 data; /* user pointer, cast to/from u64 *
On 08/20/2010 03:56 PM, Ted Ts'o wrote:
> On Fri, Aug 20, 2010 at 10:45:43AM +0200, Miloslav Trmač wrote:
>> Hello, following is a patchset providing an user-space interface to
>> the kernel crypto API. It is based on the older, BSD-compatible,
>> implementation, but the user-space interface is di
2010/8/11 Linus Walleij :
Hello,
> Hi Miloslav,
> c.f how the ALSA mixer presents a lot of things to userspace without
> using any enums at all in /dev/snd/controlC0 for card 0. For example
> in include/linux/soundcard.h you find the different control knobs
> enumerated with strings so as
Dmitry Kasatkin wrote:
> Hi,
>
> Can I use kernel Crypto API from user space?
> I remember 2 or 3 projects about it.
>
> But what is the one and only one I need? :)
I don't know which is the one you need, but I know the one I use. Check
http://home.gna.org/cryptodev-linux/
regards,
Nikos
--
To
Sebastian Andrzej Siewior wrote:
> * Phil Sutter | 2010-06-10 20:22:29 [+0200]:
>
>> Hello everyone,
> Hi Phil,
>
> please take look at [0] and [1]. From README I can tell that those two
> posts are different from you have so far.
> You might want to take a look at AF_PACKET interface. It does ze
Emanuele Cesena wrote:
> On Wed, 2010-03-17 at 14:43 +0100, Nikos Mavrogiannopoulos wrote:
>> It is one way that
>> few other OS's support as well. For this reason it is the best from the
>> user-space developer point of view to have a single API across many OS'
Emanuele Cesena wrote:
> On Wed, 2010-03-17 at 13:50 +0100, Nikos Mavrogiannopoulos wrote:
>> Hello,
>> I needed to access crypto hardware modules from userspace and I made
>> that by adding cryptodev support on top of linux-crypto. It is a
>> separate module available
Hello,
I needed to access crypto hardware modules from userspace and I made
that by adding cryptodev support on top of linux-crypto. It is a
separate module available at:
http://repo.or.cz/w/cryptodev-linux.git
It was originally based on the old cryptodev module found at
http://www.logix.cz/micha
58 matches
Mail list logo
