AEAD gcm(aes) decrypt failure

[flobro30101]

I have the encrypt line working, but cannot get the decrypt line to return anything but "Error: AEAD decryption failed due to integrity violation".

I cannot find an example for AEAD gsm(aes) decryption in the libkcapi/tests except in your test.sh, the "AEAD synchronous one shot non-aligned" tests all seem to fail .

So I figure it is more likely that I must be doing something wrong.

So here is a test script based on your test scripts to replicate my issue (please excuse the "noobiness" , I am more of a code mechanic than a cryptologist.....)

----------------------------------------

!/bin/sh

hex2bin() { local hex=$1 local dstfile=$2

    echo -n $hex | perl -pe 's/([0-9a-f]{2})/chr hex $1/gie' > $dstfile

}

GCM_MSG="507937f393b2de0fa218d0a9713262f4" GCM_KEY="5aa3d01e7242d7a64f5fd4ad25505390" GCM_IV="94af90b40cc541173d201250" GCM_AAD="0f7479e28c53d120fcf57a525e0b36a0" GCM_TAG="0f7479e28c53d120fcf57a525e0b" GCM_TAGLEN="14" GCM_EXP="e80e074e70b089c160c6d3863e8d2b75ac767d2d44412252eed41a220f31" hex2bin $GCM_KEY gcm_key hex2bin $GCM_MSG gcm_msg

exec 8< gcm_key; kcapi-enc -v -c "gcm(aes)" -e --taglen $GCM_TAGLEN --aad $GCM_AAD --keyfd 8 < gcm_msg > test.out

what is the correct decrypt line?

exec 8< gcm_key; kcapi-enc -v -c "gcm(aes)" -d --tag $GCM_TAG --aad $GCM_AAD --keyfd 8 < test.out

----------------------------------------------------------------

[flobro30101]

I think I figured it out. I removed the AAD prefix and the tag postfix from the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext. Is there a AEAD gcm(aes) for dummies that tells you these details?

Again thanks for the work you and others have done with this library/utilities.

[smuellerDD]

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag postfix from the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

[flobro30101]

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when I try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel initialized kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793" --iv aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag postfix from the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3VUGJ6PANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

[flobro30101]

Left out the strace info...

... mmap(NULL, 478533386, PROT_READ, MAP_SHARED, 6, 0) = 0xffff927af000 ftruncate(9, 478533434) = 0 write(2, "kcapi-enc - Verbose: Increase pi"..., 73kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

) = 73 fcntl(4, F_SETPIPE_SZ, 478533386) = 536870912 fcntl(5, F_SETPIPE_SZ, 478533386) = 536870912 vmsplice(5, [{iov_base="BZh91AY&SYe\206qf\0\260\320\177\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., iov_len=478533386}], 1, SPLICE_F_MORE|SPLICE_F_GIFT) = 478533386 splice(4, NULL, 10, NULL, 478533386, SPLICE_F_MORE ...

And that is where it sticks

Thanks

On Mon, Jul 18, 2022 at 10:11 AM Floyd Brown @.***> wrote:

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when I try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel initialized kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793" --iv aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag postfix from the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3VUGJ6PANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

[flobro30101]

Me again... Seems like the biggest file I can AEAD encrypt is 208800 bytes.

Any Idea what I am doing wrong?

Thanks

On Mon, Jul 18, 2022 at 10:44 AM Floyd Brown @.***> wrote:

Left out the strace info...

... mmap(NULL, 478533386, PROT_READ, MAP_SHARED, 6, 0) = 0xffff927af000 ftruncate(9, 478533434) = 0 write(2, "kcapi-enc - Verbose: Increase pi"..., 73kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

) = 73 fcntl(4, F_SETPIPE_SZ, 478533386) = 536870912 fcntl(5, F_SETPIPE_SZ, 478533386) = 536870912 vmsplice(5, [{iov_base="BZh91AY&SYe\206qf\0\260\320\177\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., iov_len=478533386}], 1, SPLICE_F_MORE|SPLICE_F_GIFT) = 478533386 splice(4, NULL, 10, NULL, 478533386, SPLICE_F_MORE ...

And that is where it sticks

Thanks

On Mon, Jul 18, 2022 at 10:11 AM Floyd Brown @.***> wrote:

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when I try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel initialized kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793" --iv aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag postfix from the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3VUGJ6PANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

[smuellerDD]

Am Montag, 18. Juli 2022, 16:11:26 CEST schrieb flobro30101:

Hi flobro30101,

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when I try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel initialized kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793" --iv aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Can you please check the contents of /proc/sys/fs/pipe-max-size ?

I doubt it can handle 450 MB.

In any case, you are starting reach a sore spot with the kernel crypto API. Think of how AEAD works: you enc/dec data, but at the end you calculate a MAC over the entire data. The kernel crypto API has a severe limitation here as it requires the entire message to be provided to the kernel before the kernel can perform the operation. I.e. you cannot send chunks of data one at a time (as done for non-AEAD algos or hashing) when using AEAD algos.

This implies user space would need to send 450 MB to the kernel in one submission. This most likely is not going to be handled well by the kernel - it would reject it because one user is not allowed to allocate that much memory (see the pipe-max-size above).

That said, it is a bug in libkcapi to not handle it gracefully. I expect that the issue is the following: the kernel AF_ALG is waiting for more data, but the kernel pipe subsystem rejects the receipt of more. So, there is no more data ending up in AF_ALG.

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag postfix

from

the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub <https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412

, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3 VUGJ6PANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Reply to this email directly or view it on GitHub: https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1187534521 You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

[flobro30101]

/proc/sys/fs/pipe-max-size = 1048576

So the question would be, would all AEAD methods suffer from the same limitation?

I would like to create a "secure hash" of a large file (after encryption with ecb(aes)), any recommendations?

Thanks

On Tue, Jul 19, 2022 at 2:02 AM smuellerDD @.***> wrote:

Am Montag, 18. Juli 2022, 16:11:26 CEST schrieb flobro30101:

Hi flobro30101,

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when I try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel initialized kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793" --iv aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Can you please check the contents of /proc/sys/fs/pipe-max-size ?

I doubt it can handle 450 MB.

In any case, you are starting reach a sore spot with the kernel crypto API. Think of how AEAD works: you enc/dec data, but at the end you calculate a MAC over the entire data. The kernel crypto API has a severe limitation here as it requires the entire message to be provided to the kernel before the kernel can perform the operation. I.e. you cannot send chunks of data one at a time (as done for non-AEAD algos or hashing) when using AEAD algos.

This implies user space would need to send 450 MB to the kernel in one submission. This most likely is not going to be handled well by the kernel

it would reject it because one user is not allowed to allocate that much memory (see the pipe-max-size above).

That said, it is a bug in libkcapi to not handle it gracefully. I expect that the issue is the following: the kernel AF_ALG is waiting for more data, but the kernel pipe subsystem rejects the receipt of more. So, there is no more data ending up in AF_ALG.

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag postfix

from

the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub < https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412

, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3 VUGJ6PANCNFSM53VJD2JA> . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1187534521 You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188633495, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXDM5JQ424DP7ORFEWDVUZAG5ANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

[smuellerDD]

Am Dienstag, 19. Juli 2022, 11:06:58 CEST schrieb flobro30101:

Hi flobro30101,

/proc/sys/fs/pipe-max-size = 1048576

So the question would be, would all AEAD methods suffer from the same limitation?

Yes.

If you have sufficient memory, for testing purposes, can you set the pipe- size-max to some 500MB or higher?

I would hazard to guess that it works then.

I would like to create a "secure hash" of a large file (after encryption with ecb(aes)), any recommendations?

You could write and encrypt-then-MAC yourself, it is pretty trivial to be honest.

1. use a common AES algorithm (ECB is the worst, CBC is good, CTR is good for data in transit)

2. select a good HMAC - e.g. SHA-256 or SHA-512.

Now do:

encryption: AES-CBC-encrypt your data HMAC the ciphertext

-> send ciphertext and HMAC to the destination

decryption: HMAC the ciphertext if (memcmp(generated HMAC, received HMAC)) return -EBADMSG; AES-CBC-decrypt your data

Thanks

On Tue, Jul 19, 2022 at 2:02 AM smuellerDD @.***> wrote:

Am Montag, 18. Juli 2022, 16:11:26 CEST schrieb flobro30101:

Hi flobro30101,

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when

I

try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel initialized kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793" --iv aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Can you please check the contents of /proc/sys/fs/pipe-max-size ?

I doubt it can handle 450 MB.

In any case, you are starting reach a sore spot with the kernel crypto API. Think of how AEAD works: you enc/dec data, but at the end you calculate a MAC over the entire data. The kernel crypto API has a severe limitation here as it requires the entire message to be provided to the kernel before the kernel can perform the operation. I.e. you cannot send chunks of data one at a time (as done for non-AEAD algos or hashing) when using AEAD algos.

This implies user space would need to send 450 MB to the kernel in one submission. This most likely is not going to be handled well by the kernel

it would reject it because one user is not allowed to allocate that much memory (see the pipe-max-size above).

That said, it is a bug in libkcapi to not handle it gracefully. I expect that the issue is the following: the kernel AF_ALG is waiting for more data, but the kernel pipe subsystem rejects the receipt of more. So, there is no more data ending up in AF_ALG.

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag

postfix

from

the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub <

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412

,

or unsubscribe

<

https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3

VUGJ6PANCNFSM53VJD2JA>

.

You are receiving this because you modified the open/close

state.Message

ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1187534521

You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub <https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188633495

, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXDM5JQ424DP7ORFEWD VUZAG5ANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Reply to this email directly or view it on GitHub: https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188796187 You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

[flobro30101]

I supposedly had available memory to expand the pipe... no deal. But I have something close to the requirements working.

Are you familiar with the kernel keychain, and what level of work it would require to add support for it to libkcapi (to support (tk...) keys) so we would not have to actually put the black key in a fd?

On Tue, Jul 19, 2022 at 5:51 AM smuellerDD @.***> wrote:

Am Dienstag, 19. Juli 2022, 11:06:58 CEST schrieb flobro30101:

Hi flobro30101,

/proc/sys/fs/pipe-max-size = 1048576

So the question would be, would all AEAD methods suffer from the same limitation?

Yes.

If you have sufficient memory, for testing purposes, can you set the pipe- size-max to some 500MB or higher?

I would hazard to guess that it works then.

I would like to create a "secure hash" of a large file (after encryption with ecb(aes)), any recommendations?

You could write and encrypt-then-MAC yourself, it is pretty trivial to be honest.

1. use a common AES algorithm (ECB is the worst, CBC is good, CTR is good for data in transit)

2. select a good HMAC - e.g. SHA-256 or SHA-512.

Now do:

encryption: AES-CBC-encrypt your data HMAC the ciphertext

-> send ciphertext and HMAC to the destination

decryption: HMAC the ciphertext if (memcmp(generated HMAC, received HMAC)) return -EBADMSG; AES-CBC-decrypt your data

Thanks

On Tue, Jul 19, 2022 at 2:02 AM smuellerDD @.***> wrote:

Am Montag, 18. Juli 2022, 16:11:26 CEST schrieb flobro30101:

Hi flobro30101,

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when

I

try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel initialized kcapi-enc - Verbose: Increase pipeseize for AEAD operation to 478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793" --iv aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Can you please check the contents of /proc/sys/fs/pipe-max-size ?

I doubt it can handle 450 MB.

In any case, you are starting reach a sore spot with the kernel crypto API. Think of how AEAD works: you enc/dec data, but at the end you calculate a MAC over the entire data. The kernel crypto API has a severe limitation here as it requires the entire message to be provided to the kernel before the kernel can perform the operation. I.e. you cannot send chunks of data one at a time (as done for non-AEAD algos or hashing) when using AEAD algos.

This implies user space would need to send 450 MB to the kernel in one submission. This most likely is not going to be handled well by the kernel

it would reject it because one user is not allowed to allocate that much memory (see the pipe-max-size above).

That said, it is a bug in libkcapi to not handle it gracefully. I expect that the issue is the following: the kernel AF_ALG is waiting for more data, but the kernel pipe subsystem rejects the receipt of more. So, there is no more data ending up in AF_ALG.

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag

postfix

from

the encrypted file and passed them in in the --aad and --tag fields respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub <

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412

,

or unsubscribe

<

https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3

VUGJ6PANCNFSM53VJD2JA>

.

You are receiving this because you modified the open/close

state.Message

ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1187534521

You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub < https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188633495

, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHF3BXDM5JQ424DP7ORFEWD VUZAG5ANCNFSM53VJD2JA> . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188796187 You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188844764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXCXKGQQXGF3AP25DZLVUZ3BFANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

[smuellerDD]

Am Mittwoch, 20. Juli 2022, 11:43:32 CEST schrieb flobro30101:

Hi flobro30101,

I supposedly had available memory to expand the pipe... no deal. But I have something close to the requirements working.

Ok, then you have an issue...

Are you familiar with the kernel keychain, and what level of work it would require to add support for it to libkcapi (to support (tk...) keys) so we would not have to actually put the black key in a fd?

I have not really looked into that part. Patches are welcome. Maybe I get around evetually to add this logic.

On Tue, Jul 19, 2022 at 5:51 AM smuellerDD @.***> wrote:

Am Dienstag, 19. Juli 2022, 11:06:58 CEST schrieb flobro30101:

Hi flobro30101,

/proc/sys/fs/pipe-max-size = 1048576

So the question would be, would all AEAD methods suffer from the same limitation?

Yes.

If you have sufficient memory, for testing purposes, can you set the pipe- size-max to some 500MB or higher?

I would hazard to guess that it works then.

I would like to create a "secure hash" of a large file (after encryption with ecb(aes)), any recommendations?

You could write and encrypt-then-MAC yourself, it is pretty trivial to be honest.

1. use a common AES algorithm (ECB is the worst, CBC is good, CTR is good for data in transit)

2. select a good HMAC - e.g. SHA-256 or SHA-512.

Now do:

encryption: AES-CBC-encrypt your data HMAC the ciphertext

-> send ciphertext and HMAC to the destination

decryption: HMAC the ciphertext if (memcmp(generated HMAC, received HMAC)) return -EBADMSG; AES-CBC-decrypt your data

Thanks

On Tue, Jul 19, 2022 at 2:02 AM smuellerDD @.***> wrote:

Am Montag, 18. Juli 2022, 16:11:26 CEST schrieb flobro30101:

Hi flobro30101,

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when

I

try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel

initialized

kcapi-enc - Verbose: Increase pipeseize for AEAD operation to

478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793"

--iv

aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Can you please check the contents of /proc/sys/fs/pipe-max-size ?

I doubt it can handle 450 MB.

In any case, you are starting reach a sore spot with the kernel crypto API. Think of how AEAD works: you enc/dec data, but at the end you

calculate a

MAC over the entire data. The kernel crypto API has a severe limitation

here

as it requires the entire message to be provided to the kernel before the kernel can perform the operation. I.e. you cannot send chunks of data one at a

time

(as done for non-AEAD algos or hashing) when using AEAD algos.

This implies user space would need to send 450 MB to the kernel in one submission. This most likely is not going to be handled well by the kernel

it would reject it because one user is not allowed to allocate that

much

memory (see the pipe-max-size above).

That said, it is a bug in libkcapi to not handle it gracefully. I

expect

that the issue is the following: the kernel AF_ALG is waiting for more data, but the kernel pipe subsystem rejects the receipt of more. So, there is no more data ending up in AF_ALG.

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag

postfix

from

the encrypted file and passed them in in the --aad and --tag

fields

respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub <

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412

,

or unsubscribe

<

https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3

VUGJ6PANCNFSM53VJD2JA>

.

You are receiving this because you modified the open/close

state.Message

ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1187534521

You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub <

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188633495

,

or unsubscribe

<

https://github.com/notifications/unsubscribe-auth/AHF3BXDM5JQ424DP7ORFEWD

VUZAG5ANCNFSM53VJD2JA>

.

You are receiving this because you modified the open/close

state.Message

ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188796187

You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub <https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188844764

, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXCXKGQQXGF3AP25DZL VUZ3BFANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Reply to this email directly or view it on GitHub: https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1190060578 You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

[flobro30101]

For your review...

My attempt (it does work) to supply keys via kernel keychain using "capi:" prefix for --cipher value and --key containing keyname so command name looks like: kcapi-enc -v -c "capi:tk(ecb(aes))" -e --key pers:tmpkey -i test.tar.bz2 -o kcapi-out.enc

On Mon, Jul 25, 2022 at 3:15 PM smuellerDD @.***> wrote:

Am Mittwoch, 20. Juli 2022, 11:43:32 CEST schrieb flobro30101:

Hi flobro30101,

I supposedly had available memory to expand the pipe... no deal. But I have something close to the requirements working.

Ok, then you have an issue...

Are you familiar with the kernel keychain, and what level of work it would require to add support for it to libkcapi (to support (tk...) keys) so we would not have to actually put the black key in a fd?

I have not really looked into that part. Patches are welcome. Maybe I get around evetually to add this logic.

On Tue, Jul 19, 2022 at 5:51 AM smuellerDD @.***> wrote:

Am Dienstag, 19. Juli 2022, 11:06:58 CEST schrieb flobro30101:

Hi flobro30101,

/proc/sys/fs/pipe-max-size = 1048576

So the question would be, would all AEAD methods suffer from the same limitation?

Yes.

If you have sufficient memory, for testing purposes, can you set the pipe- size-max to some 500MB or higher?

I would hazard to guess that it works then.

I would like to create a "secure hash" of a large file (after encryption with ecb(aes)), any recommendations?

You could write and encrypt-then-MAC yourself, it is pretty trivial to be honest.

1. use a common AES algorithm (ECB is the worst, CBC is good, CTR is good for data in transit)

2. select a good HMAC - e.g. SHA-256 or SHA-512.

Now do:

encryption: AES-CBC-encrypt your data HMAC the ciphertext

-> send ciphertext and HMAC to the destination

decryption: HMAC the ciphertext if (memcmp(generated HMAC, received HMAC)) return -EBADMSG; AES-CBC-decrypt your data

Thanks

On Tue, Jul 19, 2022 at 2:02 AM smuellerDD @.***> wrote:

Am Montag, 18. Juli 2022, 16:11:26 CEST schrieb flobro30101:

Hi flobro30101,

Is there a reason you can think of why AEAD encryption with kcapi-enc "freezes" with a large file size (450MB)? I can do small files, but when

I

try to encrypt sensitive data, I see libkcapi - Verbose: communication for gcm(aes) with kernel

initialized

kcapi-enc - Verbose: Increase pipeseize for AEAD operation to

478533386

And just sits there, ps shows: root 1512 1.2 11.6 469380 468624 pts/1 S+ 10:08 0:00 kcapi-enc -v -c...

command line is: exec 8<password; kcapi-enc -v -c "gcm(aes)" -e --taglen 16 --aad

"5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793"

--iv

aac774c39e399e7d6371ec1d -i bigfile.tar.bz2 -o test.enc --keyfd 8

Can you please check the contents of /proc/sys/fs/pipe-max-size ?

I doubt it can handle 450 MB.

In any case, you are starting reach a sore spot with the kernel crypto API. Think of how AEAD works: you enc/dec data, but at the end you

calculate a

MAC over the entire data. The kernel crypto API has a severe limitation

here

as it requires the entire message to be provided to the kernel before the kernel can perform the operation. I.e. you cannot send chunks of data one at a

time

(as done for non-AEAD algos or hashing) when using AEAD algos.

This implies user space would need to send 450 MB to the kernel in one submission. This most likely is not going to be handled well by the kernel

it would reject it because one user is not allowed to allocate that

much

memory (see the pipe-max-size above).

That said, it is a bug in libkcapi to not handle it gracefully. I

expect

that the issue is the following: the kernel AF_ALG is waiting for more data, but the kernel pipe subsystem rejects the receipt of more. So, there is no more data ending up in AF_ALG.

Thanks

On Fri, Jul 15, 2022 at 12:57 PM smuellerDD @.***> wrote:

Am Freitag, 15. Juli 2022, 15:02:12 CEST schrieb flobro30101:

Hi flobro30101,

I think I figured it out. I removed the AAD prefix and the tag

postfix

from

the encrypted file and passed them in in the --aad and --tag

fields

respectively and looks like the decrypted value is the aad+cleartext.

Yes, that is the intended approach.

Is there a AEAD gcm(aes) for dummies that tells you these details?

kcapi-enc(1) should do the trick, no?

Again thanks for the work you and others have done with this library/utilities.

Ciao Stephan

— Reply to this email directly, view it on GitHub <

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1185728412

,

or unsubscribe

<

https://github.com/notifications/unsubscribe-auth/AHF3BXGVL53FR7GA7TBWZC3

VUGJ6PANCNFSM53VJD2JA>

.

You are receiving this because you modified the open/close

state.Message

ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1187534521

You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub <

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188633495

,

or unsubscribe

<

https://github.com/notifications/unsubscribe-auth/AHF3BXDM5JQ424DP7ORFEWD

VUZAG5ANCNFSM53VJD2JA>

.

You are receiving this because you modified the open/close

state.Message

ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188796187

You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub < https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1188844764

, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHF3BXCXKGQQXGF3AP25DZL VUZ3BFANCNFSM53VJD2JA> . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Reply to this email directly or view it on GitHub:

https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1190060578 You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan

— Reply to this email directly, view it on GitHub https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1194507618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXA4QYCN4LLFO3DARK3VV3RVDANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

[smuellerDD]

Am Dienstag, 26. Juli 2022, 16:23:17 CEST schrieb flobro30101:

Hi flobro30101,

For your review...

My attempt (it does work) to supply keys via kernel keychain using "capi:" prefix for --cipher value and --key containing keyname so command name looks like: kcapi-enc -v -c "capi:tk(ecb(aes))" -e --key pers:tmpkey -i test.tar.bz2 -o kcapi-out.enc

Interesting. Who pulls the key from the keyring, I wonder?

Ciao Stephan

[flobro30101]

line 861: ret = keyctl_read (key, (char*) keybuf, sizeof(keybuf)); reads the keyname from the keychain with the --key supplied name (only if --cipher has the "capi:" prefix)

Thanks

Floyd Brown 678.453.6069

On Wed, Jul 27, 2022 at 1:27 AM smuellerDD @.***> wrote:

Am Dienstag, 26. Juli 2022, 16:23:17 CEST schrieb flobro30101:

Hi flobro30101,

For your review...

My attempt (it does work) to supply keys via kernel keychain using "capi:" prefix for --cipher value and --key containing keyname so command name looks like: kcapi-enc -v -c "capi:tk(ecb(aes))" -e --key pers:tmpkey -i test.tar.bz2 -o kcapi-out.enc

Interesting. Who pulls the key from the keyring, I wonder?

Ciao Stephan

— Reply to this email directly, view it on GitHub https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1196280781, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXAB7BLNSTMQC6HNYHDVWDCEXANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

[flobro30101]

line 861: ret = keyctl_read (key, (char*) keybuf, sizeof(keybuf)); reads the keyname from the keychain with the --key supplied name (only if --cipher has the "capi:" prefix)

On Wed, Jul 27, 2022 at 1:27 AM smuellerDD @.***> wrote:

Am Dienstag, 26. Juli 2022, 16:23:17 CEST schrieb flobro30101:

Hi flobro30101,

For your review...

My attempt (it does work) to supply keys via kernel keychain using "capi:" prefix for --cipher value and --key containing keyname so command name looks like: kcapi-enc -v -c "capi:tk(ecb(aes))" -e --key pers:tmpkey -i test.tar.bz2 -o kcapi-out.enc

Interesting. Who pulls the key from the keyring, I wonder?

Ciao Stephan

— Reply to this email directly, view it on GitHub https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1196280781, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXAB7BLNSTMQC6HNYHDVWDCEXANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

[smuellerDD]

Am Mittwoch, 27. Juli 2022, 12:36:08 CEST schrieb flobro30101:

Hi flobro30101,

line 861: ret = keyctl_read (key, (char*) keybuf, sizeof(keybuf)); reads the keyname from the keychain with the --key supplied name (only if --cipher has the "capi:" prefix)

Sorry for the delay, vacation time :-)

If you have a patch, I would be happy to integrate it.

Thanks

Floyd Brown 678.453.6069

On Wed, Jul 27, 2022 at 1:27 AM smuellerDD @.***> wrote:

Am Dienstag, 26. Juli 2022, 16:23:17 CEST schrieb flobro30101:

Hi flobro30101,

For your review...

My attempt (it does work) to supply keys via kernel keychain using

"capi:"

prefix for --cipher value and --key containing keyname so command name looks like: kcapi-enc -v -c "capi:tk(ecb(aes))" -e --key pers:tmpkey -i test.tar.bz2

-o

kcapi-out.enc

Interesting. Who pulls the key from the keyring, I wonder?

Ciao Stephan

— Reply to this email directly, view it on GitHub <https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1196280781

, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHF3BXAB7BLNSTMQC6HNYHD VWDCEXANCNFSM53VJD2JA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Reply to this email directly or view it on GitHub: https://github.com/smuellerDD/libkcapi/issues/142#issuecomment-1196557948 You are receiving this because you commented.

Message ID: @.***>

Ciao Stephan