ocf-linux-users Mailing List for Open Cryptographic Framework for Linux
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users — Anything and everything ocf-linux related
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(39) |
Oct
(16) |
Nov
(7) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(10) |
Feb
(1) |
Mar
(18) |
Apr
(8) |
May
(14) |
Jun
(12) |
Jul
(35) |
Aug
(11) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
| 2009 |
Jan
(20) |
Feb
(12) |
Mar
(31) |
Apr
(20) |
May
(31) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(2) |
Dec
(6) |
| 2010 |
Jan
(20) |
Feb
(10) |
Mar
(16) |
Apr
|
May
(17) |
Jun
|
Jul
(2) |
Aug
(30) |
Sep
(6) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
(6) |
May
(20) |
Jun
(2) |
Jul
(13) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(19) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: James H. <jam...@gm...> - 2022-10-08 09:14:02
|
The legacy crypto_hash interface was removed as of kernel version
4.6.0, adapt this interface to be compatible with the replacement
crypto_shash interface.
Signed-off-by: James Hilliard <jam...@gm...>
---
ocf/cryptosoft.c | 185 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 185 insertions(+)
diff --git a/ocf/cryptosoft.c b/ocf/cryptosoft.c
index caf9c06..d903b6e 100644
--- a/ocf/cryptosoft.c
+++ b/ocf/cryptosoft.c
@@ -56,6 +56,9 @@
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,29)
#include <crypto/hash.h>
#endif
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0)
+#include <linux/highmem.h>
+#endif
#include <cryptodev.h>
#include <uio.h>
@@ -184,6 +187,188 @@ static struct kmem_cache *swcr_req_cache;
#define crypto_alloc_comp(X, Y, Z) crypto_alloc_tfm(X, mode)
#define plain(X) #X , 0
#else
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0)
+ #define hash_desc shash_desc
+ #define crypto_free_hash crypto_free_shash
+ #define crypto_hash_tfm crypto_shash_tfm
+ #define crypto_alloc_hash crypto_alloc_shash
+ #define crypto_hash_digestsize crypto_shash_digestsize
+ #define crypto_hash_setkey crypto_shash_setkey
+ #define crypto_has_hash crypto_has_ahash
+ #define crypto_hash_cast(X) container_of(X, struct crypto_shash, base)
+
+struct crypto_hash_walk {
+ char *data;
+
+ unsigned int offset;
+ unsigned int alignmask;
+
+ struct page *pg;
+ unsigned int entrylen;
+
+ unsigned int total;
+ struct scatterlist *sg;
+
+ unsigned int flags;
+};
+
+static int hash_walk_next(struct crypto_hash_walk *walk)
+{
+ unsigned int alignmask = walk->alignmask;
+ unsigned int offset = walk->offset;
+ unsigned int nbytes = min(walk->entrylen,
+ ((unsigned int)(PAGE_SIZE)) - offset);
+
+ if (walk->flags & CRYPTO_ALG_ASYNC)
+ walk->data = kmap(walk->pg);
+ else
+ walk->data = kmap_atomic(walk->pg);
+ walk->data += offset;
+
+ if (offset & alignmask) {
+ unsigned int unaligned = alignmask + 1 - (offset & alignmask);
+
+ if (nbytes > unaligned)
+ nbytes = unaligned;
+ }
+
+ walk->entrylen -= nbytes;
+ return nbytes;
+}
+
+static int hash_walk_new_entry(struct crypto_hash_walk *walk)
+{
+ struct scatterlist *sg;
+
+ sg = walk->sg;
+ walk->offset = sg->offset;
+ walk->pg = sg_page(walk->sg) + (walk->offset >> PAGE_SHIFT);
+ walk->offset = offset_in_page(walk->offset);
+ walk->entrylen = sg->length;
+
+ if (walk->entrylen > walk->total)
+ walk->entrylen = walk->total;
+ walk->total -= walk->entrylen;
+
+ return hash_walk_next(walk);
+}
+
+static int crypto_hash_walk_first_compat(struct shash_desc *sdesc,
+ struct crypto_hash_walk *walk,
+ struct scatterlist *sg, unsigned int len)
+{
+ walk->total = len;
+
+ if (!walk->total) {
+ walk->entrylen = 0;
+ return 0;
+ }
+
+ walk->alignmask = crypto_shash_alignmask(sdesc->tfm);
+ walk->sg = sg;
+ walk->flags = sdesc->flags & CRYPTO_TFM_REQ_MASK;
+
+ return hash_walk_new_entry(walk);
+}
+
+static inline void crypto_yield(u32 flags)
+{
+ if (flags & CRYPTO_TFM_REQ_MAY_SLEEP)
+ cond_resched();
+}
+
+static int crypto_hash_walk_done(struct crypto_hash_walk *walk, int err)
+{
+ unsigned int alignmask = walk->alignmask;
+ unsigned int nbytes = walk->entrylen;
+
+ walk->data -= walk->offset;
+
+ if (nbytes && walk->offset & alignmask && !err) {
+ walk->offset = ALIGN(walk->offset, alignmask + 1);
+ walk->data += walk->offset;
+
+ nbytes = min(nbytes,
+ ((unsigned int)(PAGE_SIZE)) - walk->offset);
+ walk->entrylen -= nbytes;
+
+ return nbytes;
+ }
+
+ if (walk->flags & CRYPTO_ALG_ASYNC)
+ kunmap(walk->pg);
+ else {
+ kunmap_atomic(walk->data);
+ /*
+ * The may sleep test only makes sense for sync users.
+ * Async users don't need to sleep here anyway.
+ */
+ crypto_yield(walk->flags);
+ }
+
+ if (err)
+ return err;
+
+ if (nbytes) {
+ walk->offset = 0;
+ walk->pg++;
+ return hash_walk_next(walk);
+ }
+
+ if (!walk->total)
+ return 0;
+
+ walk->sg = sg_next(walk->sg);
+
+ return hash_walk_new_entry(walk);
+}
+
+static int shash_compat_update(struct shash_desc *desc, struct scatterlist *sg,
+ unsigned int len)
+{
+ struct crypto_hash_walk walk;
+ int nbytes;
+
+ for (nbytes = crypto_hash_walk_first_compat(desc, &walk, sg, len);
+ nbytes > 0; nbytes = crypto_hash_walk_done(&walk, nbytes))
+ nbytes = crypto_shash_update(desc, walk.data, nbytes);
+
+ return nbytes;
+}
+
+static int crypto_hash_digest(struct shash_desc *desc, struct scatterlist *sg,
+ unsigned int nbytes, u8 *out)
+{
+ unsigned int offset = sg->offset;
+ int err;
+
+ if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
+ void *data;
+
+ desc->flags = desc->flags;
+
+ data = kmap_atomic(sg_page(sg));
+ err = crypto_shash_digest(desc, data + offset, nbytes, out);
+ kunmap_atomic(data);
+ crypto_yield(desc->flags);
+ goto out;
+ }
+
+ err = crypto_shash_init(desc);
+ if (err)
+ goto out;
+
+ err = shash_compat_update(desc, sg, nbytes);
+ if (err)
+ goto out;
+
+ err = crypto_shash_final(desc, out);
+
+out:
+ return err;
+}
+
+#endif /* if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0) */
#define ecb(X) "ecb(" #X ")" , 0
#define cbc(X) "cbc(" #X ")" , 0
#define hmac(X) "hmac(" #X ")" , 0
--
2.37.3
|
|
From: James H. <jam...@gm...> - 2022-10-08 09:13:19
|
The crypto_alloc_ablkcipher symbol was removed as of linux version 4.8.0. Signed-off-by: James Hilliard <jam...@gm...> --- ocf/cryptosoft.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ocf/cryptosoft.c b/ocf/cryptosoft.c index caf9c06..841d41e 100644 --- a/ocf/cryptosoft.c +++ b/ocf/cryptosoft.c @@ -190,9 +190,11 @@ static struct kmem_cache *swcr_req_cache; #define plain(X) #X , 0 #endif /* if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19) */ +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22) || LINUX_VERSION_CODE >= KERNEL_VERSION(4,8,0) +#define crypto_alloc_ablkcipher(a,b,c) (NULL) +#endif #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22) /* no ablkcipher in older kernels */ -#define crypto_alloc_ablkcipher(a,b,c) (NULL) #define crypto_ablkcipher_tfm(x) ((struct crypto_tfm *)(x)) #define crypto_ablkcipher_set_flags(a, b) /* nop */ #define crypto_ablkcipher_setkey(x, y, z) (-EINVAL) -- 2.37.3 |
|
From: James H. <jam...@gm...> - 2022-10-08 09:12:53
|
The linux/signal.h header was moved to linux/sched/signal.h as
of linux version 4.11.0.
As such linux/sched/signal.h is not available on linux below 4.11.0.
Signed-off-by: James Hilliard <jam...@gm...>
---
ocf/crypto.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/ocf/crypto.c b/ocf/crypto.c
index 4e50328..5691b2a 100644
--- a/ocf/crypto.c
+++ b/ocf/crypto.c
@@ -73,7 +73,11 @@ __FBSDID("$FreeBSD: src/sys/opencrypto/crypto.c,v 1.16 2005/01/07 02:29:16 imp E
#include <linux/slab.h>
#include <linux/wait.h>
#include <linux/sched.h>
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,11,0)
+#include <linux/signal.h>
+#else
#include <linux/sched/signal.h>
+#endif
#include <linux/spinlock.h>
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,4)
#include <linux/kthread.h>
--
2.37.3
|
|
From: Fabrice F. <fon...@gm...> - 2022-06-03 21:11:05
|
Dear all, As reported in [1], ocf-linux fails to build with kernel >= 5.6 because timespec has been hidden since [2]. This build failure is also raised on buildroot [3]. Do you plan to release a new version to fix this issue? Best Regards, Fabrice [1] https://sourceforge.net/p/ocf-linux/mailman/message/37373267/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c766d1472c70d25ad475cf56042af1652e792b23 [3] http://autobuild.buildroot.org/results/91a/91ad285f07c5a9492ae98fe38abd438b6ab198c2/build-end.log |
|
From: David M. <uc...@gm...> - 2021-10-26 02:02:06
|
You should start with the 20171122 release as a minimum :-) If that gives you problems let me know, its probably time we had an upodate to that. Dan W wrote the following: > I'm on Ubuntu 20.04, just downloaded OCF and was trying to follow the > readme file instructions, but at the first step, make ocf_make, I got > compiler errors with acc, min and max, namely, > > In file included from > /home/dd/Downloads/zips/ocf-linux-20120127/ocf/crypto.c:80: > /home/dd/Downloads/zips/ocf-linux-20120127/ocf/./cryptodev.h:278:18: error: > field ‘acc’ has incomplete type > 278 | struct timespec acc; /* total accumulated time */ > | ^~~ > /home/dd/Downloads/zips/ocf-linux-20120127/ocf/./cryptodev.h:279:18: error: > field ‘min’ has incomplete type > 279 | struct timespec min; /* min time */ > | ^~~ > /home/dd/Downloads/zips/ocf-linux-20120127/ocf/./cryptodev.h:280:18: error: > field ‘max’ has incomplete type > 280 | struct timespec max; /* max time */ > > I do have some C/C++ experience, could try to figure it out, but I'd rather > report this, first of all, and make sure I apply the right fix. > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users -- David McCullough, da...@sp..., Ph: 0410 560 763 |
|
From: Dan W <dan...@gm...> - 2021-10-25 22:22:57
|
I'm on Ubuntu 20.04, just downloaded OCF and was trying to follow the
readme file instructions, but at the first step, make ocf_make, I got
compiler errors with acc, min and max, namely,
In file included from
/home/dd/Downloads/zips/ocf-linux-20120127/ocf/crypto.c:80:
/home/dd/Downloads/zips/ocf-linux-20120127/ocf/./cryptodev.h:278:18: error:
field ‘acc’ has incomplete type
278 | struct timespec acc; /* total accumulated time */
| ^~~
/home/dd/Downloads/zips/ocf-linux-20120127/ocf/./cryptodev.h:279:18: error:
field ‘min’ has incomplete type
279 | struct timespec min; /* min time */
| ^~~
/home/dd/Downloads/zips/ocf-linux-20120127/ocf/./cryptodev.h:280:18: error:
field ‘max’ has incomplete type
280 | struct timespec max; /* max time */
I do have some C/C++ experience, could try to figure it out, but I'd rather
report this, first of all, and make sure I apply the right fix.
|
|
From: YIyun M. <man...@gm...> - 2016-09-12 11:34:35
|
Hi , My Marvell a385 board only support OCF API, but linux kernel use crypto API to encrypt/decrypt ESP packets. Is there any guide or sample code to convert OCF API driver to crypto API? Regards, Yiyun Meng |
|
From: Bill R. <ros...@gm...> - 2016-07-23 11:18:25
|
Hi List; I am using ocf-linux in an openwrt application and have run into MAX_DATA_LEN (64K-1) and E2BIG errors in CRYPTO_AES_CBC mode. As a consequence, I need to split the input buffer into chunks < MAX_DATA_LEN and process chunks individually and assemble the resultant plaintext / ciphertext chunks into a large output buffer. Google has sparse results and no code regarding this issue. Wikipedia indicates this is possible by feeding the previous iv to the next block operation: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_ch aining_.28CBC.29 Description: CBC encryption.svg Description: CBC decryption.svg QUESTIONS/POINT: 1 - Is this possible using ocf-linux? 2 - Has anyone run into / solved this issue and have (pseudo) code (best practice) to share to save me re-inventing the wheel? My current encrypt / decrypt functions (working for < MAX_DATA_LEN) follow: int aes_encrypt(struct cryptodev_ctx* ctx, const void* iv, const void* plaintext, void* ciphertext, size_t size) { struct crypt_op cryp; void* p; /* check plaintext and ciphertext alignment */ if (ctx->alignmask) { p = (void*)(((unsigned long)plaintext + ctx->alignmask) & ~ctx->alignmask); if (plaintext != p) { DebugPrintf( DEBUG_ERR, "%s: plaintext is not aligned\n", __func__); return ERROR; } p = (void*)(((unsigned long)ciphertext + ctx->alignmask) & ~ctx->alignmask); if (ciphertext != p) { DebugPrintf( DEBUG_ERR, "%s: ciphertext is not aligned\n", __func__); return ERROR; } } memset(&cryp, 0, sizeof(cryp)); /* Encrypt data.in to data.encrypted */ cryp.ses = ctx->sess.ses; cryp.len = size; cryp.src = (void*)plaintext; cryp.dst = ciphertext; cryp.iv = (void*)iv; cryp.op = COP_ENCRYPT; if (ioctl(ctx->cfd, CIOCCRYPT, &cryp)) { DebugPrintf( DEBUG_ERR, "%s: ioctl(CIOCCRYPT)\n", __func__); return ERROR; } return OK; } int aes_decrypt(struct cryptodev_ctx* ctx, const void* iv, const void* ciphertext, void* plaintext, size_t size) { struct crypt_op cryp; void* p; /* check plaintext and ciphertext alignment */ if (ctx->alignmask) { p = (void*)(((unsigned long)plaintext + ctx->alignmask) & ~ctx->alignmask); if (plaintext != p) { DebugPrintf( DEBUG_ERR, "%s: plaintext is not aligned\n", __func__); return ERROR; } p = (void*)(((unsigned long)ciphertext + ctx->alignmask) & ~ctx->alignmask); if (ciphertext != p) { DebugPrintf( DEBUG_ERR, "%s: ciphertext is not aligned\n", __func__); return ERROR; } } memset(&cryp, 0, sizeof(cryp)); /* Decrypt ciphertext to plaintext */ cryp.ses = ctx->sess.ses; cryp.len = size; cryp.src = (void*)ciphertext; cryp.dst = plaintext; cryp.iv = (void*)iv; cryp.op = COP_DECRYPT; if (ioctl(ctx->cfd, CIOCCRYPT, &cryp)) { DebugPrintf( DEBUG_ERR, "%s: ioctl(CIOCCRYPT)\n", __func__); return ERROR; } return OK; } Thanks; Bill Ross |
|
From: David M. <uc...@gm...> - 2015-10-21 22:54:29
|
Hi Nicolas,
The best thing to do for now is turn off CONFIG_OCF_RANDOMHARVEST
so that the random support does not get built. I don't think the cavium
had and sources of random info that it could help with from memory
so it probably doesn't gain you anything,
Cheers,
Davidm
Nicolas FOURNIL wrote the following:
> Hello
>
> I'm trying to use a Cavium Octeon XL and so I need to install OCF Framework.
>
> I use stock debian "strech"
>
> I push patch ... fix some rejects and I tried to build my kernel modules
> and I get finaly :
>
> ....
> CC [M] crypto/async_tx/async_memcpy.o
> CC [M] crypto/async_tx/async_xor.o
> CC [M] crypto/async_tx/async_pq.o
> CC [M] crypto/async_tx/async_raid6_recov.o
> CC [M] crypto/ocf/crypto.o
> CC [M] crypto/ocf/criov.o
> CC [M] crypto/ocf/random.o
> crypto/ocf/random.c: In function ‘random_proc’:
> crypto/ocf/random.c:202:2: error: implicit declaration of function
> ‘daemonize’ [-Werror=implicit-function-declaration]
> daemonize("ocf-random");
> ^
> cc1: some warnings being treated as errors
> scripts/Makefile.build:258: recipe for target 'crypto/ocf/random.o' failed
>
> It seems that API of 3.8+ kernel has changed. Is someone working on a fix ?
>
> Thanks
>
> Nicolas F.
> ------------------------------------------------------------------------------
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
--
David McCullough, uc...@gm..., Ph: 0410 560 763
|
|
From: Nicolas F. <nic...@gm...> - 2015-10-21 16:02:09
|
Hello
I'm trying to use a Cavium Octeon XL and so I need to install OCF Framework.
I use stock debian "strech"
I push patch ... fix some rejects and I tried to build my kernel modules
and I get finaly :
....
CC [M] crypto/async_tx/async_memcpy.o
CC [M] crypto/async_tx/async_xor.o
CC [M] crypto/async_tx/async_pq.o
CC [M] crypto/async_tx/async_raid6_recov.o
CC [M] crypto/ocf/crypto.o
CC [M] crypto/ocf/criov.o
CC [M] crypto/ocf/random.o
crypto/ocf/random.c: In function ‘random_proc’:
crypto/ocf/random.c:202:2: error: implicit declaration of function
‘daemonize’ [-Werror=implicit-function-declaration]
daemonize("ocf-random");
^
cc1: some warnings being treated as errors
scripts/Makefile.build:258: recipe for target 'crypto/ocf/random.o' failed
It seems that API of 3.8+ kernel has changed. Is someone working on a fix ?
Thanks
Nicolas F.
|
|
From: Sundar S. <sun...@gm...> - 2015-04-02 13:56:25
|
Not sure if I remember the version I used for TI OMAP HW accelerators. It did not support AES CTR mode. You have to add the mode. It was a simple change. Been many years since I worked on that. I lost the change. Perhaps the newer versions have the support already? Someone might be able to provide you more information. Thanks, Sundar On Thursday, April 2, 2015, Rakshith Rao <rak...@gm...> wrote: > ---------- Forwarded message ---------- > From: "Rakshith Rao" <rak...@gm... > <javascript:_e(%7B%7D,'cvml','rak...@gm...');>> > Date: 2 Apr 2015 19:19 > Subject: Clarification regarding CTR mode > To: "ocf-linux-users" <ocf...@li... > <javascript:_e(%7B%7D,'cvml','ocf...@li...');>> > Cc: > > Hi, > I am using the hardware accelerator of am335x processor. Along with > that I am using ocf-linux-20100325. Does it support the CTR mode of AES? > > Thank you, > Rakshith Rao. > |
|
From: Rakshith R. <rak...@gm...> - 2015-04-02 13:51:23
|
---------- Forwarded message ----------
From: "Rakshith Rao" <rak...@gm...>
Date: 2 Apr 2015 19:19
Subject: Clarification regarding CTR mode
To: "ocf-linux-users" <ocf...@li...>
Cc:
Hi,
I am using the hardware accelerator of am335x processor. Along with
that I am using ocf-linux-20100325. Does it support the CTR mode of AES?
Thank you,
Rakshith Rao.
|
|
From: Rakshith R. <rak...@gm...> - 2015-03-16 14:42:30
|
Hi,
I am using OCF. I downloaded ocf-20120127 and applied patch to
linux-3.12 kernel, generated cryptodev.ko and cryptosoft.ko, did insmod in
the development board. The problem I am facing is in the development board
I can use only CBC mode of AES alogorithm. It is failing in stream cipher
modes like CFB or OFB. When I give command 'openssl speed -evp
aes-256-cfb' in command line, instead of hardware mode the command got
executed in software mode.
when I looked into the source code, in file ocf/c7108/aes-7108.c, in
the function c7108_newsession() all other ciphers modes except CBC are
commented out. Is the problem I am facing because of this. Or any other
modification required?
Thank you,
Rakshith Rao M,
|
|
From: Rakshith R. <rak...@gm...> - 2015-03-16 14:21:15
|
Hi,
I am using ocf and I want to make use of a stream cipher mode cfb
(cipher feedback) of AES algotithm.
I downloaded ocf-20120127 and applied the patch to linux-3.12 kernel. Then
generated the cryptodev.ko and cryptosoft.ko, insmod in the development
board. Now the problem I am facing is using hardware accelerator mode only
CBC cipher mode is working and its failing in cfb mode. I want to make use
of stream cipher.
When I looked the source code in ocf/c7108/aes-7108.c line 398,
c7108_newsession() function
all other cipher modes except CBC are commented out. is this the reason for
my problem?
|
|
From: anand r. <one...@ya...> - 2014-08-08 08:47:33
|
Hi David, Did you get a chance to reproduce the setup and issue. I have made no progress on this as I am unable to find the reason. BRs, Anand On Tuesday, July 29, 2014 3:44 AM, David McCullough <uc...@gm...> wrote: anand rao wrote the following: > > > Hi David, > > I have few more information which I missed earlier. > In my OpenSSL configuration along with HAVE_CRYPTODEV I have also enabled USE_CRYPTODEV_DIGESTS. > > If I don't enable USE_CRYPTODEV_DIGESTS option then I am observing below error. That is interesting as I never use USE_CRYPTODEV_DIGESTS, thanks for the update. Cheers, Davidm > root@OpenWrt:/etc/ssl# openssl req -x509 -engine cryptodev -new -newkey rsa:1024 > -keyout private/cakey.pem -days 3650 -out cacert.pem > engine "cryptodev" set. > Generating a 1024 bit RSA private key > ..++++++ > ................................................++++++ > writing new private key to 'private/cakey.pem' > Enter PEM pass phrase: > Verifying - Enter PEM pass phrase: > ----- > You are about to be asked to enter information that will be incorporated > into your certificate request. > What you are about to enter is what is called a Distinguished Name or a DN. > There are quite a few fields but you can leave some blank > For some fields there will be a default value, > If you enter '.', the field will be left blank. > ----- > Country Name (2 letter code) [AU]:problems making Certificate Request > > > BRs, > Anand > > > > > > On Friday, July 25, 2014 6:54 PM, David McCullough <uc...@gm...> wrote: > > > anand rao wrote the following: > > Hi David, > > >>You should not need to patch any of the 1.0.0 or later versions for use > > > > >>with OCF. All the "main" changes should already be in there. > > > > >>Are you appling any patches to 1.0.1g ?' > > > > No. I have not applied any patches to 1.0.1g. > > As I mentioned without applying any patches this issue is reproducible. > > No problems, just making sure I can reproduce you setup :-) > > -- > David McCullough, uc...@gm..., Ph: 0410 560 763 -- David McCullough, da...@sp..., Ph: 0410 560 763 |
|
From: David M. <uc...@gm...> - 2014-08-08 05:23:54
|
anand rao wrote the following: > Hi David, > > Did you get a chance to reproduce the setup and issue. > I have made no progress on this as I am unable to find the reason. Sorry, not yet :-( Keep bugging me and I promise to get to it :-) Cheers, Davidm > On Tuesday, July 29, 2014 3:44 AM, David McCullough <uc...@gm...> wrote: > > anand rao wrote the following: > > > > > > Hi David, > > > > I have few more information which I missed earlier. > > In my OpenSSL configuration along with HAVE_CRYPTODEV I have also enabled USE_CRYPTODEV_DIGESTS. > > > > If I don't enable USE_CRYPTODEV_DIGESTS option then I am observing below error. > > That is interesting as I never use USE_CRYPTODEV_DIGESTS, thanks for the > update. > > Cheers, > Davidm > > > root@OpenWrt:/etc/ssl# openssl req -x509 -engine cryptodev -new -newkey rsa:1024 > > -keyout private/cakey.pem -days 3650 -out cacert.pem > > engine "cryptodev" set. > > Generating a 1024 bit RSA private key > > ..++++++ > > ................................................++++++ > > writing new private key to 'private/cakey.pem' > > Enter PEM pass phrase: > > Verifying - Enter PEM pass phrase: > > ----- > > You are about to be asked to enter information that will be incorporated > > into your certificate request. > > What you are about to enter is what is called a Distinguished Name or a DN. > > There are quite a few fields but you can leave some blank > > For some fields there will be a default value, > > If you enter '.', the field will be left blank. > > ----- > > Country Name (2 letter code) [AU]:problems making Certificate Request > > > > > > BRs, > > Anand > > > > > > > > > > > > On Friday, July 25, 2014 6:54 PM, David McCullough <uc...@gm...> wrote: > > > > > > anand rao wrote the following: > > > Hi David, > > > >>You should not need to patch any of the 1.0.0 or later versions for use > > > > > > >>with OCF. All the "main" changes should already be in there. > > > > > > >>Are you appling any patches to 1.0.1g ?' > > > > > > No. I have not applied any patches to 1.0.1g. > > > As I mentioned without applying any patches this issue is reproducible. > > > > No problems, just making sure I can reproduce you setup :-) > > > > -- > > David McCullough, uc...@gm..., Ph: 0410 560 763 > > -- > David McCullough, da...@sp..., Ph: 0410 560 763 -- David McCullough, da...@sp..., Ph: 0410 560 763 |
|
From: David M. <uc...@gm...> - 2014-07-28 22:14:47
|
anand rao wrote the following: > > > Hi David, > > I have few more information which I missed earlier. > In my OpenSSL configuration along with HAVE_CRYPTODEV I have also enabled USE_CRYPTODEV_DIGESTS. > > If I don't enable USE_CRYPTODEV_DIGESTS option then I am observing below error. That is interesting as I never use USE_CRYPTODEV_DIGESTS, thanks for the update. Cheers, Davidm > root@OpenWrt:/etc/ssl# openssl req -x509 -engine cryptodev -new -newkey rsa:1024 > -keyout private/cakey.pem -days 3650 -out cacert.pem > engine "cryptodev" set. > Generating a 1024 bit RSA private key > ..++++++ > ................................................++++++ > writing new private key to 'private/cakey.pem' > Enter PEM pass phrase: > Verifying - Enter PEM pass phrase: > ----- > You are about to be asked to enter information that will be incorporated > into your certificate request. > What you are about to enter is what is called a Distinguished Name or a DN. > There are quite a few fields but you can leave some blank > For some fields there will be a default value, > If you enter '.', the field will be left blank. > ----- > Country Name (2 letter code) [AU]:problems making Certificate Request > > > BRs, > Anand > > > > > > On Friday, July 25, 2014 6:54 PM, David McCullough <uc...@gm...> wrote: > > > anand rao wrote the following: > > Hi David, > > >>You should not need to patch any of the 1.0.0 or later versions for use > > > > >>with OCF. All the "main" changes should already be in there. > > > > >>Are you appling any patches to 1.0.1g ?' > > > > No. I have not applied any patches to 1.0.1g. > > As I mentioned without applying any patches this issue is reproducible. > > No problems, just making sure I can reproduce you setup :-) > > -- > David McCullough, uc...@gm..., Ph: 0410 560 763 -- David McCullough, da...@sp..., Ph: 0410 560 763 |
|
From: anand r. <one...@ya...> - 2014-07-28 14:11:55
|
Hi David, I have few more information which I missed earlier. In my OpenSSL configuration along with HAVE_CRYPTODEV I have also enabled USE_CRYPTODEV_DIGESTS. If I don't enable USE_CRYPTODEV_DIGESTS option then I am observing below error. root@OpenWrt:/etc/ssl# openssl req -x509 -engine cryptodev -new -newkey rsa:1024 -keyout private/cakey.pem -days 3650 -out cacert.pem engine "cryptodev" set. Generating a 1024 bit RSA private key ..++++++ ................................................++++++ writing new private key to 'private/cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:problems making Certificate Request BRs, Anand On Friday, July 25, 2014 6:54 PM, David McCullough <uc...@gm...> wrote: anand rao wrote the following: > Hi David, > >>You should not need to patch any of the 1.0.0 or later versions for use > > >>with OCF. All the "main" changes should already be in there. > > >>Are you appling any patches to 1.0.1g ?' > > No. I have not applied any patches to 1.0.1g. > As I mentioned without applying any patches this issue is reproducible. No problems, just making sure I can reproduce you setup :-) -- David McCullough, uc...@gm..., Ph: 0410 560 763 |
|
From: David M. <uc...@gm...> - 2014-07-25 13:24:21
|
anand rao wrote the following: > Hi David, > >>You should not need to patch any of the 1.0.0 or later versions for use > > >>with OCF. All the "main" changes should already be in there. > > >>Are you appling any patches to 1.0.1g ?' > > No. I have not applied any patches to 1.0.1g. > As I mentioned without applying any patches this issue is reproducible. No problems, just making sure I can reproduce you setup :-) -- David McCullough, uc...@gm..., Ph: 0410 560 763 |
|
From: anand r. <one...@ya...> - 2014-07-25 06:33:45
|
Hi David, >>You should not need to patch any of the 1.0.0 or later versions for use >>with OCF. All the "main" changes should already be in there. >>Are you appling any patches to 1.0.1g ?' No. I have not applied any patches to 1.0.1g. As I mentioned without applying any patches this issue is reproducible. Cheers, Davidm -- David McCullough, uc...@gm..., Ph: 0410 560 763 |
|
From: David M. <uc...@gm...> - 2014-07-24 22:56:35
|
anand rao wrote the following: > Hi David, > > >>I am not aware of any change between 1.0.0g and 1.0.1g that would have this affect. > > This issue is reproduced on 1.0.1e also. > > > >>Which HW driver are you using ? > > This issue is reproducible with OCF software crypto also, without any HW registered with OCF. Really, thats interesting. > >>Which version of OCF are you using ? > > I am using ocf-linux-20120127 , my kernel version is 3.2.26 > > >> Perhaps you should try posting the query to the openssl mailing list. They may be more uptodate > >>on openssl changes that may affect this code, > > I have posted this on OpenSSL forum, the response was that OpenSSL was broken because of the patches applied. I have applied only OCF patch, but even without any patches applied the issue is observed. > > I have mentioned that I was using OCF underneath, there were no further response to my query. Bummer. You should not need to patch any of the 1.0.0 or later versions for use with OCF. All the "main" changes should already be in there. Are you appling any patches to 1.0.1g ? Cheers, Davidm -- David McCullough, uc...@gm..., Ph: 0410 560 763 |
|
From: anand r. <one...@ya...> - 2014-07-24 15:00:58
|
Hi David, >>I am not aware of any change between 1.0.0g and 1.0.1g that would have this affect. This issue is reproduced on 1.0.1e also. >>Which HW driver are you using ? This issue is reproducible with OCF software crypto also, without any HW registered with OCF. >>Which version of OCF are you using ? I am using ocf-linux-20120127 , my kernel version is 3.2.26 >> Perhaps you should try posting the query to the openssl mailing list. They may be more uptodate >>on openssl changes that may affect this code, I have posted this on OpenSSL forum, the response was that OpenSSL was broken because of the patches applied. I have applied only OCF patch, but even without any patches applied the issue is observed. I have mentioned that I was using OCF underneath, there were no further response to my query. Best Regards, Anand |
|
From: David M. <uc...@gm...> - 2014-07-24 10:31:40
|
anand rao wrote the following: > Hi, > > I am using openssl 1.0.1g to create a CA and generate certificates. > > I am facing an issue while generating the device certificates. > After creating the ca certificate using below command > > # openssl req -x509 -new -newkey rsa:1024 -keyout private/cakey.pem -days 3650 -out cacert.pem > > when we try to display the contents the signature algorithm is shown as itu-t instead of sha1WithRSAEncryption > > #openssl x509 -in cacert.pem -noout -text > > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 96:15:a3:26:59:5f:46:1d > Signature Algorithm: itu-t > Issuer: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com > Validity > Not Before: Jun 14 12:08:24 2013 GMT > Not After : Jun 12 12:08:24 2023 GMT > Subject: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (1024 bit) > Modulus: > 00:c1:73:b4:37:ed:d1:1f:fb:bf:63:b0:8a:91:82: > a8:f0:83:4d:5a:32:9b:5d:bc:23:06:3f:d4:fc:77: > cf:83:0f:ab:ac:35:46:98:02:e5:a3:cc:89:30:34: > 05:3f:80:ad:33:ae:dc:7e:57:60:e2:02:d6:c9:6b: > b8:76:f7:56:e6:0f:44:c4:71:3a:cf:e1:59:8e:b4: > 4b:6a:4a:de:59:25:4d:58:74:f0:82:27:0e:35:34: > 72:86:9e:7c:a3:c8:cb:ba:55:8f:d5:8f:2f:cd:a0: > 1f:e8:89:7c:74:0e:92:a0:de:72:d1:33:96:41:42: > bc:44:d0:20:29:cf:7b:2c:a7 > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Subject Key Identifier: > C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A > X509v3 Authority Key Identifier: > keyid:C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A > DirName:/C=US/ST=LA/L=CA/O=Internet Widgits Pty Ltd/OU=crop/CN=GWCA/subjectAltName=DNS:www.evmweb.com > serial:96:15:A3:26:59:5F:46:1D > > X509v3 Basic Constraints: > CA:TRUE > Signature Algorithm: itu-t > a0:0e:98:f2:46:4e:0e:b5:d9:ff:f2:e5:57:24:d2:81:66:2e: > 4a:2b:3c:f6:02:48:4a:37:d8:4d:d9:70:b2:01:43:f4:71:fc: > 92:27:a9:d0:0b:9f:1a:c2:b7:54:3e:67:f3:0e:71:76:15:c0: > c2:0f:b7:3a:13:de:93:4e:42:27:f9:5a:bb:d9:9e:e8:19:55: > 88:7e:4b:d6:3a:b7:2d:46:3f:79:13:f4:c7:da:59:37:95:ef: > 15:47:91:2a:32:4d:0d:ba:6f:a6:13:c3:57:87:ac:70:53:98: > 41:11:8d:ee:af:3d:46:d1:48:bb:f7:de:5d:00:a4:f1:59:c2: > 0c:56 > > when we try to sign a device certificate I am getting below error. > > # openssl ca -policy policy_anything -out certs/evm1gwcert.pem -infiles evm1gwCSR.pem > > Using configuration from /etc/ssl/openssl.cnf > Enter pass phrase for /etc/ssl/private/cakey.pem: > Check that the request matches the signature > Signature verification problems.. > > > This issue is not observed when we disable OCF, I mean if remove OCF modules OR compile OpenSSL without HAVE_CRYPTODEV then this issues is not seen. > Has something changed between OpenSSL version 1.0.0g and 1.0.1g, which OCF is not compatible with? I am not aware of any change between 1.0.0g and 1.0.1g that would have this affect. Which HW driver are you using ? Which version of OCF are you using ? I will try and reproduce this if I get a chance. Perhaps you should try posting the query to the openssl mailing list. They may be more uptodate on openssl changes that may affect this code, Cheers, Davidm -- David McCullough, da...@sp..., Ph: 0410 560 763 |
|
From: anand r. <one...@ya...> - 2014-07-23 07:27:18
|
Hi, I am using openssl 1.0.1g to create a CA and generate certificates. I am facing an issue while generating the device certificates. After creating the ca certificate using below command # openssl req -x509 -new -newkey rsa:1024 -keyout private/cakey.pem -days 3650 -out cacert.pem when we try to display the contents the signature algorithm is shown as itu-t instead of sha1WithRSAEncryption #openssl x509 -in cacert.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 96:15:a3:26:59:5f:46:1d Signature Algorithm: itu-t Issuer: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com Validity Not Before: Jun 14 12:08:24 2013 GMT Not After : Jun 12 12:08:24 2023 GMT Subject: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c1:73:b4:37:ed:d1:1f:fb:bf:63:b0:8a:91:82: a8:f0:83:4d:5a:32:9b:5d:bc:23:06:3f:d4:fc:77: cf:83:0f:ab:ac:35:46:98:02:e5:a3:cc:89:30:34: 05:3f:80:ad:33:ae:dc:7e:57:60:e2:02:d6:c9:6b: b8:76:f7:56:e6:0f:44:c4:71:3a:cf:e1:59:8e:b4: 4b:6a:4a:de:59:25:4d:58:74:f0:82:27:0e:35:34: 72:86:9e:7c:a3:c8:cb:ba:55:8f:d5:8f:2f:cd:a0: 1f:e8:89:7c:74:0e:92:a0:de:72:d1:33:96:41:42: bc:44:d0:20:29:cf:7b:2c:a7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A X509v3 Authority Key Identifier: keyid:C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A DirName:/C=US/ST=LA/L=CA/O=Internet Widgits Pty Ltd/OU=crop/CN=GWCA/subjectAltName=DNS:www.evmweb.com serial:96:15:A3:26:59:5F:46:1D X509v3 Basic Constraints: CA:TRUE Signature Algorithm: itu-t a0:0e:98:f2:46:4e:0e:b5:d9:ff:f2:e5:57:24:d2:81:66:2e: 4a:2b:3c:f6:02:48:4a:37:d8:4d:d9:70:b2:01:43:f4:71:fc: 92:27:a9:d0:0b:9f:1a:c2:b7:54:3e:67:f3:0e:71:76:15:c0: c2:0f:b7:3a:13:de:93:4e:42:27:f9:5a:bb:d9:9e:e8:19:55: 88:7e:4b:d6:3a:b7:2d:46:3f:79:13:f4:c7:da:59:37:95:ef: 15:47:91:2a:32:4d:0d:ba:6f:a6:13:c3:57:87:ac:70:53:98: 41:11:8d:ee:af:3d:46:d1:48:bb:f7:de:5d:00:a4:f1:59:c2: 0c:56 when we try to sign a device certificate I am getting below error. # openssl ca -policy policy_anything -out certs/evm1gwcert.pem -infiles evm1gwCSR.pem Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for /etc/ssl/private/cakey.pem: Check that the request matches the signature Signature verification problems.. This issue is not observed when we disable OCF, I mean if remove OCF modules OR compile OpenSSL without HAVE_CRYPTODEV then this issues is not seen. Has something changed between OpenSSL version 1.0.0g and 1.0.1g, which OCF is not compatible with? Please suggest. Best Regards, Anand |
|
From: Guillaume FLORENCE-C. <g.f...@la...> - 2014-06-03 08:49:22
|
Hi,
I'm using crosstool-ng for cross-compilation on virtualized Linux Mint
Debian Edition over Windows 8 using Virtual box. This tool installs
different software included ocf-linux
Problem: Antivirus Avast updated is running on host and detects a trojan
in ocf-linux-20120127.tar.gz :
URL
hxxp://sunet.dl.sourceforge.net/project/ocf-linux/ocf-linux/20120127/ocf-linux-20120127.tar.gz|ocf-linux-20120127.tar|ocf-linux-20120127\crypto-tools\cryptotest.gdb
Infection
ELF:BitCoinMiner-H [Trj]
Does someone have an explanation? Is it a false positive?
Regards,
Guillaume
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
|
4 messages has been excluded from this view by a project administrator.