Skipping last few bytes of file when FileSource

[Richard Závodný]

Hi. I need skip last 512bytes from the file. This solution not working: 
int fileSize = boost::filesystem::file_size("first.txt");

CryptoPP::FileSource sourceFile("first.txt", false, new CryptoPP::FileSink(
"second.txt"));
sourceFile.Pump(fileSize - 512);

How could i achieve this?

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

AES CCM decryption/verification.

[Daniel Karcz]

Hi,

I have to understand decryption process of Crypto CCM implementation.
I'm using the first example AE (authentication/encryption) from Crypto++ 
Wiki. 

https://www.cryptopp.com/wiki/CCM_Mode

Here is my example output from this program:

key: 6DFB2E83D016999B8F4CA9B564AB2B6A
 iv: 37F1A6DD11DD2D14C3CABBAD

plain text: Authenticated Encryption
cipher text: 61CBA7195D8F9619C4190D61D0D953301FFE2169785BAC5501E768279E7B
C5AA
recovered text: Authenticated Encryption

Now, here is my understanding of decryption process:

Text "Authenticated Encryption" is 24 bytes long so the firs 24 bytes are 
cipher:

"61CBA7195D8F9619C4190D61D0D953301FFE2169785BAC55"

we have remain 8 bytes and it is correct because  

TAG_SIZE = 8, so the last 8 bytes are the tag "01E768279E7BC5AA".


remain I have to write only encryption/veryfication function (because I'm 
facing Linux program using Crypto++ with embedded system which Crypto++ is 
not supporting). I have AES in CTR and CBC Crypto hardware support on that 
chip.

I have started from generating counter blocks:

so I tooked the iv 37F1A6DD11DD2D14C3CABBAD and I have add 3 bytes 
(counter) and tooked it as input data to AES ECB encryption with key  
6DFB2E83D016999B8F4CA9B564AB2B6A 

 
 Key: 6DFB2E83D016999B8F4CA9B564AB2B6A
 Algorithm: AES-128
 Mode: ECB
 Crypto operation: Encryption
 Data: 37F1A6DD11DD2D14C3CABBAD00

 
 Encrypted data: 77B133ED82AE801FCABAC8F51BCA4141

Now I was suposing that I have a first counter block, so I've made a XOR 
operation with first 16 bytes of cipher text

Here is result  


16 7A 94 F4 DF 21 16 06 0E A3 C5 94 CB 13 12 71

and when I changed this into ASCII it is far away from first 16 bytes of 
plain text: "Authenticated En".

I'm getting crazy with this because it suppose to work that way, and I'm 
out of ideas with it.

Please help

















-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: error: 'mutex' in namespace 'std' does not name a type

[Marcel Raad]

On Saturday, November 4, 2017 at 10:36:30 PM UTC+1, Jeffrey Walton wrote:
> I tired to setup a MinGW testing environment several times but it either (1) 
> never worked or (2) broke immediately. On the rare occasions I could compile 
> and link I was able to file some MinGW bug reports but they were never 
> acknowledged.
> 
> 
> 
> I'm happy to try to support it, but we can't do it without folks testing and 
> filing the bug reports. Without the testers and the bug reports things will 
> likely stay broken.

I'll try testing MinGW again in the coming days. I was very busy in the last 
few weeks, but that should get better now.

Gene, what MinGW flavor are you using? The original 32-bit-only one from 
mingw.org?

The problem is that there's no threading support in libstdc++ when using native 
Windows threads. Compilation works fine for me with the pthreads version of 
MinGW-w64. It should also be possible to use a third-party pthreads library 
with the original mingw.org MinGW as mentioned here [1], but I've never tried 
that yet.

Hopefully it's also possible to distinguish between threading libraries used at 
compile time and set CRYPTOPP_CXX11_SYNCHRONIZATION accordingly. I'll look into 
that soon.

[1] http://www.mingw.org/wiki/pthreads_library

Marcel

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.