Re: [cryptopp-users] HMACs of files
It can work with:
https://gist.github.com/thomasb9511/f570ecad82055b34a27ec9e706f596c9
But it sidesteps the pipeline for verification.
On Sunday, May 21, 2023 at 7:28:44 AM UTC-4 Tom wrote:
> When dealing with the `SignatureVerificationFilter`, similar issues arise
> due to the requirement of having the "tag" at either the beginning or end
> of the initial part of the pipeline. Adding the "tag" to the filename
> within a pipeline that starts with `FileSource` does not resolve this
> problem. Consequently, `FileSource` may attempt to load an incorrect file
> or, when using an `ifstream`, cause a compile-time type mismatch.
>
> While attaching the "tag" to a file that already has it may seem logically
> sound, this approach can disrupt the functionality of certain files. For
> example, executable files cannot have the "tag" prepended, and appending
> the "tag" can lead to extraction tools generating errors about extra data,
> especially in the case of archives. Furthermore, this method renders simple
> hash checks invalid, especially if the hash was generated before the "tag"
> was added, as the file's content has been altered.
> On Sunday, May 21, 2023 at 12:56:43 AM UTC-4 Tom wrote:
>
>> Okay.
>>
>> However, when I looked at the information provided in this link:
>> https://www.cryptopp.com/wiki/HashVerificationFilter#String_and_File_Sources,
>>
>> it appears that the method suggested to avoid memory usage doesn't actually
>> achieve that goal, as the line FileSource fs("zero.dat", true); in the
>> verification step is performing as intended.
>>
>> Unfortunately, I am unable to use FileSource fs("zero.dat", false, new
>> HashVerificationFilter(sha256, new StringSink(digest))); or FileSource
>> fs("zero.dat", true... either, because it's unclear how to associate the
>> digest with the input file.
>> On Saturday, May 20, 2023 at 6:48:40 PM UTC-4 Jeffrey Walton wrote:
>>
>>> On Sat, May 20, 2023 at 4:45 PM Jeffrey Walton
>>> wrote:
>>> >
>>> > On Sat, May 20, 2023 at 3:00 PM Tom wrote:
>>> > >
>>> > > calling `FileSource fs("zero.dat", true);` seems to allocate the
>>> memory.
>>> >
>>> > Try the overload which takes a std::istream reference:
>>> > https://www.cryptopp.com/wiki/FileSource
>>>
>>> I took another look... The issue is you passed 'true' for 'pumpAll'.
>>> That reads the entire file, and puts it in an output buffer for the
>>> next filter.
>>>
>>> Use 'false' instead, and then call 'PumpAll()' manually. Something
>>> like the example. Something like this should suffice:
>>>
>>> FileSource fs("zero.dat", false, new Filter(..., new Sink(...)));
>>> fs.PumpAll();
>>>
>>> It should pump in 4k blocks.
>>>
>>> Jeff
>>>
>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/cryptopp-users/16098bdd-0361-4b54-9860-c39b8c6147d4n%40googlegroups.com.
Re: [cryptopp-users] HMACs of files
When dealing with the `SignatureVerificationFilter`, similar issues arise
due to the requirement of having the "tag" at either the beginning or end
of the initial part of the pipeline. Adding the "tag" to the filename
within a pipeline that starts with `FileSource` does not resolve this
problem. Consequently, `FileSource` may attempt to load an incorrect file
or, when using an `ifstream`, cause a compile-time type mismatch.
While attaching the "tag" to a file that already has it may seem logically
sound, this approach can disrupt the functionality of certain files. For
example, executable files cannot have the "tag" prepended, and appending
the "tag" can lead to extraction tools generating errors about extra data,
especially in the case of archives. Furthermore, this method renders simple
hash checks invalid, especially if the hash was generated before the "tag"
was added, as the file's content has been altered.
On Sunday, May 21, 2023 at 12:56:43 AM UTC-4 Tom wrote:
> Okay.
>
> However, when I looked at the information provided in this link:
> https://www.cryptopp.com/wiki/HashVerificationFilter#String_and_File_Sources,
> it appears that the method suggested to avoid memory usage doesn't actually
> achieve that goal, as the line FileSource fs("zero.dat", true); in the
> verification step is performing as intended.
>
> Unfortunately, I am unable to use FileSource fs("zero.dat", false, new
> HashVerificationFilter(sha256, new StringSink(digest))); or FileSource
> fs("zero.dat", true... either, because it's unclear how to associate the
> digest with the input file.
> On Saturday, May 20, 2023 at 6:48:40 PM UTC-4 Jeffrey Walton wrote:
>
>> On Sat, May 20, 2023 at 4:45 PM Jeffrey Walton
>> wrote:
>> >
>> > On Sat, May 20, 2023 at 3:00 PM Tom wrote:
>> > >
>> > > calling `FileSource fs("zero.dat", true);` seems to allocate the
>> memory.
>> >
>> > Try the overload which takes a std::istream reference:
>> > https://www.cryptopp.com/wiki/FileSource
>>
>> I took another look... The issue is you passed 'true' for 'pumpAll'.
>> That reads the entire file, and puts it in an output buffer for the
>> next filter.
>>
>> Use 'false' instead, and then call 'PumpAll()' manually. Something
>> like the example. Something like this should suffice:
>>
>> FileSource fs("zero.dat", false, new Filter(..., new Sink(...)));
>> fs.PumpAll();
>>
>> It should pump in 4k blocks.
>>
>> Jeff
>>
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/cryptopp-users/e13f1557-9234-4669-b0f9-aed8a6a6377cn%40googlegroups.com.
Re: [cryptopp-users] HMACs of files
Okay.
However, when I looked at the information provided in this link:
https://www.cryptopp.com/wiki/HashVerificationFilter#String_and_File_Sources,
it appears that the method suggested to avoid memory usage doesn't actually
achieve that goal, as the line FileSource fs("zero.dat", true); in the
verification step is performing as intended.
Unfortunately, I am unable to use FileSource fs("zero.dat", false, new
HashVerificationFilter(sha256, new StringSink(digest))); or FileSource
fs("zero.dat", true... either, because it's unclear how to associate the
digest with the input file.
On Saturday, May 20, 2023 at 6:48:40 PM UTC-4 Jeffrey Walton wrote:
> On Sat, May 20, 2023 at 4:45 PM Jeffrey Walton wrote:
> >
> > On Sat, May 20, 2023 at 3:00 PM Tom wrote:
> > >
> > > calling `FileSource fs("zero.dat", true);` seems to allocate the
> memory.
> >
> > Try the overload which takes a std::istream reference:
> > https://www.cryptopp.com/wiki/FileSource
>
> I took another look... The issue is you passed 'true' for 'pumpAll'.
> That reads the entire file, and puts it in an output buffer for the
> next filter.
>
> Use 'false' instead, and then call 'PumpAll()' manually. Something
> like the example. Something like this should suffice:
>
> FileSource fs("zero.dat", false, new Filter(..., new Sink(...)));
> fs.PumpAll();
>
> It should pump in 4k blocks.
>
> Jeff
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/cryptopp-users/7af8a6f5-5cc2-47d2-b35b-21c131bbf774n%40googlegroups.com.
Re: [cryptopp-users] HMACs of files
calling `FileSource fs("zero.dat", true);` seems to allocate the memory.
On Wednesday, September 8, 2021 at 7:24:28 PM UTC-4 Jeffrey Walton wrote:
> On Wed, Sep 8, 2021 at 6:46 AM Jeffrey Walton wrote:
> >
> > On Tue, Sep 7, 2021 at 7:45 AM Tom wrote:
> > >
> > > I can create HMACs of files using pipelines via filesources but... I
> can't seem to figure out to verify the HMAC without throwing the file into
> a string in memory.
> > >
> > > like this:
> > >
> > > StringSource(plain + mac, true, new HashVerificationFilter(hmac, NULL,
> flags) ); // StringSource
> > >
> > > Is there a way to use a FileSource without loading the file fully into
> memory?
> > >
> > > I think its possible but do I append the hmac if I use a file?
> >
> > Yeah, that's a problem. We should have some documentation covering it.
>
> Here is the documentation:
>
> https://www.cryptopp.com/wiki/HashVerificationFilter#String_and_File_Sources
>
> Jeff
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/cryptopp-users/4d2be937-ba8a-4125-99bb-b6abba00b9bcn%40googlegroups.com.
[cryptopp-users] Website SSL cert seems to have expired.
It seems the website has had its SSL cert expire. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/cryptopp-users/d66d5767-db93-4b7f-abdc-9785facbe9f0n%40googlegroups.com.
[cryptopp-users] HMACs of files
I can create HMACs of files using pipelines via filesources but... I can't seem to figure out to verify the HMAC without throwing the file into a string in memory. like this: StringSource(plain + mac, true, new HashVerificationFilter(hmac, NULL, flags) ); // StringSource Is there a way to use a FileSource without loading the file fully into memory? I think its possible but do I append the hmac if I use a file? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/cryptopp-users/ba96d8c3-b229-4a20-a132-4b81c5020759n%40googlegroups.com.
[cryptopp-users] Re: Size of ECP points in ECDSA
Thanks for the response! I was looking for some kind of constant that I can use in a constexpr context (for setting array sizes and suchlike), but apparently that actually doesn't exist. Still, good to get some insight in the other functions available. Tom On Saturday, 27 April 2019 04:54:43 UTC+2, Jeffrey Walton wrote: > > > > On Friday, April 26, 2019 at 5:47:27 AM UTC-4, Tom Smeding wrote: >> >> Hi all, >> >> The GetPublicElement() method of the >> CryptoPP::ECDSA::PublicKey class returns a value of type >> CryptoPP::ECP::Point, which represents the elliptic curve point that is >> the public key. >> This public key consists of two integers, x and y, that, if I am >> correct, are always 32 bytes in size (though their MinEncodedSize could >> be less if the leading byte is zero). >> >> However, in my application I would like to be able to get this size (32 >> bytes) from the CryptoPP API somewhere, to reduce the number of magic >> constants in my code. >> Is this exported somewhere? I have not been able to find it, but that may >> be my fault. >> > > So this is kind of a trick question... > > An x or y component of a coordinate only needs to be as large as a field > element. When serialized leading 0's are usually preserved. For example, > that means secp160 would use field element size of 20-bytes. However, SEC-1 > says to use subgroup order and not field elements. So in the case of > secp160, the component would use 21 bytes, not 20. SEC-2 was supposed to > switch to field element but the change did not appear to occur. Also see > https://github.com/weidai11/cryptopp/issues/785 . > > With that said, you can use this for a private key (just the exponent): > > GetAbstractGroupParameters().GetSubgroupOrder().ByteCount(); > > And you can use the following for a public point ((x,y) pair or just the (y) > part of the coordinate). The boolean argument means "compressed". Compressed > means just the y-coordinate. > > GetAbstractGroupParameters().GetEncodedElementSize(false); > > Jeff > > -- You received this message because you are subscribed to "Crypto++ Users". More information about Crypto++ and this group is available at http://www.cryptopp.com and http://groups.google.com/forum/#!forum/cryptopp-users. --- 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.
[cryptopp-users] Size of ECP points in ECDSA
Hi all, The GetPublicElement() method of the CryptoPP::ECDSA::PublicKey class returns a value of type CryptoPP::ECP::Point, which represents the elliptic curve point that is the public key. This public key consists of two integers, x and y, that, if I am correct, are always 32 bytes in size (though their MinEncodedSize could be less if the leading byte is zero). However, in my application I would like to be able to get this size (32 bytes) from the CryptoPP API somewhere, to reduce the number of magic constants in my code. Is this exported somewhere? I have not been able to find it, but that may be my fault. Thanks in advance, Tom Smeding -- You received this message because you are subscribed to "Crypto++ Users". More information about Crypto++ and this group is available at http://www.cryptopp.com and http://groups.google.com/forum/#!forum/cryptopp-users. --- 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.
[cryptopp-users] Re: Does Cryptopp support variable digest sizes for BLAKE2?
On Sunday, February 24, 2019 at 1:36:46 PM UTC-5, Tom wrote: > > BLAKE2b_384:F54AEB1C4848FB988266C7E347C15F > 6CB4B2D896FC7A7127074C956508192ED8C7644AC492999532207986D10EF43652 > BLAKE2b_320: > F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127074C956508192ED8C7644AC492999532 > BLAKE2b_256: > F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127074C956508192ED8 > BLAKE2b_224:F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127074C9565 > BLAKE2b_192:F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127 > BLAKE2b_128:F54AEB1C4848FB988266C7E347C15F6C > BLAKE2b_64: F54AEB1C4848FB98 > > Changing the digest length should produce different results -- You received this message because you are subscribed to "Crypto++ Users". More information about Crypto++ and this group is available at http://www.cryptopp.com and http://groups.google.com/forum/#!forum/cryptopp-users. --- 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.
[cryptopp-users] Re: Does Cryptopp support variable digest sizes for BLAKE2?
Thanks, but I seem to be producing incorrect results.
The expected result for a BLAKE2b-384 digest of "1234567890"
is
5a5f07b659b97436674e047c1f68d2513aea801e8722aeba5af5a3bf4fd20032b1e0182078389a1b76bae77f1d536950
and the program below is producing a digest
of
F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127074C956508192ED8C7644AC492999532207986D10EF43652
std::string hash(std::string input)
{
CryptoPP::byte const* pbData = (CryptoPP::byte*)input.data();
unsigned int nDataLen = input.length();
CryptoPP::byte abDigest[48];
CryptoPP::BLAKE2b(48).CalculateTruncatedDigest(abDigest, 48, pbData,
nDataLen);
return std::string((char*)abDigest, 48);
}
std::string to_hex(const std::string& input)
{
CryptoPP::byte const* pbData = (CryptoPP::byte*)input.data();
unsigned int nDataLen = input.length();
std::string output;
CryptoPP::HexEncoder hex(new CryptoPP::StringSink(output));
hex.Put(pbData, nDataLen);
hex.MessageEnd();
return output;
}
int main(int argc, char* argv[])
{
std::string text = "1234567890";
std::cout << to_hex(hash(text)) std::endl;
return 0;
}
Also changing the digest length for other lengths seems to produce just the
first `x` bytes of a larger hash i.e. for the string "1234567890"
I.e. the following:
BLAKE2b_384:
F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127074C956508192ED8C7644AC492999532207986D10EF43652
BLAKE2b_320:
F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127074C956508192ED8C7644AC492999532
BLAKE2b_256:
F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127074C956508192ED8
BLAKE2b_224:F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127074C9565
BLAKE2b_192:F54AEB1C4848FB988266C7E347C15F6CB4B2D896FC7A7127
BLAKE2b_128:F54AEB1C4848FB988266C7E347C15F6C
BLAKE2b_64: F54AEB1C4848FB98
--
You received this message because you are subscribed to "Crypto++ Users". More
information about Crypto++ and this group is available at
http://www.cryptopp.com and
http://groups.google.com/forum/#!forum/cryptopp-users.
---
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.
[cryptopp-users] Does Cryptopp support variable digest sizes for BLAKE2?
std::string hash(std::string input)
{
CryptoPP::byte const* pbData = (CryptoPP::byte*)input.data();
unsigned int nDataLen = input.length();
CryptoPP::byte abDigest[CryptoPP::BLAKE2b::DIGESTSIZE];
CryptoPP::BLAKE2b().CalculateDigest(abDigest, pbData, nDataLen);
return std::string((char*)abDigest, CryptoPP::BLAKE2b::DIGESTSIZE);
}
this the function I'm using, is it possible to specify a nondefault digest
size?
--
You received this message because you are subscribed to "Crypto++ Users". More
information about Crypto++ and this group is available at
http://www.cryptopp.com and
http://groups.google.com/forum/#!forum/cryptopp-users.
---
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: Valgrind reports uninitialised value of size 8 from CryptoPP::Rijndael::Base::UncheckedSetKey
Forget that, I was talking rubbish. The problem seems to have occurred because I was using a b**tardised version of the source consisting mostly of cryptopp560 but with an updated copy of rijndael.cpp. When I switch the whole lot to the HEAD of the trunk the problem disappears. On Jul 30, 12:08 pm, Tom thw...@ntlworld.com wrote: Hi all, When I use valgrind with my application it reports: ==6920== Use of uninitialised value of size 8 ==6920== at 0x7DF95EB: CryptoPP::Rijndael::Base::UncheckedSetKey(unsigned char const*, unsigned, CryptoPP::NameValuePairs const) (rijndael.cpp:280) ==6920== by 0x7D0CEE5: CryptoPP::SimpleKeyingInterface::SetKey(unsigned char const*, unsigned long, CryptoPP::NameValuePairs const) (cryptlib.cpp:56) ==6920== by 0x7DF6312: CryptoPP::RandomPool::GenerateIntoBufferedTransformation(CryptoPP::BufferedTransformation, std::string const, unsigned long long) (randpool.cpp:38) ==6920== by 0x7D0D984: CryptoPP::RandomNumberGenerator::GenerateBlock(unsigned char*, unsigned long) (cryptlib.cpp:260) ... my code ... This is with r488 of rijndael.cpp, where line 280 is: word32 x = (word32(Se[GETBYTE(temp, 2)]) 24) ^ (word32(Se[GETBYTE(temp, 1)]) 16) ^ (word32(Se[GETBYTE(temp, 0)]) 8) ^ Se[GETBYTE(temp, 3)]; It looks like the issue is with Se which whilst declared in rijndael.h never seems to get initialised anywhere in the code. Can somebody explain what/why is going on? Thanks, Tom -- 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.
Re: Decrypted AES file is 16 characters short - what am I doing wrong?
The problem turned out to be in CryptStreamBuffer::GetNextChar() and
was fixed by replacing:
// If there are no more bytes currently available then pump the source
if (m_StreamTransformationFilter-MaxRetrievable() == 0) {
m_Source-Pump(1024);
}
With the following which ewnsure that the last few bytes are
processed:
// If there are no more bytes currently available from the filter then
// pump the source.
if (m_StreamTransformationFilter-MaxRetrievable() == 0) {
if (0 == m_Source-Pump(1024)) {
// This seems to be required to ensure the final bytes are
readable
// from the filter.
m_StreamTransformationFilter-
ChannelMessageEnd(CryptoPP::DEFAULT_CHANNEL);
}
}
Tom
On Jun 16, 6:46 pm, Don donfai...@gmail.com wrote:
here is your answer.
It has to do with the cipher that you picked.
ECB Mode is electronic codebook. ECB was originally specified by NIST
in FIPS 81. The standard, issued in 1981, only offers confidentiality.
Other modes, such as CCM and GCM, offer authenticated encryption which
places an integrity assurance over the encrpyted data.
BECB mode does not use an IV, and the plain text must be padded to
the block size of the cipher/B. For additional information on this
mode, see Block Cipher Modes of Operation.
On Jun 16, 12:05 pm, Don donfai...@gmail.com wrote:
Hi
I compiled your code and your stopping on the last BLOCKSIZE boundary.
Bet your losing the remainder and only getting even BLOCKSIZE out put.
In other words your not losing 16 bytes your losing the last 16
bytes.
don
I will see if I can find out why.
On Jun 11, 10:54 am, Tom thw...@ntlworld.com wrote:
Hi,
To answer my own previous question (http://groups.google.com/group/
cryptopp-users/browse_thread/thread/721dbd6fa5992a57) I wrote the code
given at the end of this post.
However it appears that DecryptFile() is not attempting to decrypt the
last 16 bytes (block size) of the encrypted file. Can anybody tell me
what I am doing wrong?
Yours truly,
Tom
----
// Runtime Includes
#include iostream
// Crypto++ Includes
#include aes.h
#include modes.h // xxx_Mode
#include filters.h // StringSource and
// StreamTransformation
#include files.h
using namespace std;
class CryptStreamBuffer: public std::streambuf {
public:
CryptStreamBuffer(istream encryptedInput,
CryptoPP::StreamTransformation c);
CryptStreamBuffer(ostream encryptedOutput,
CryptoPP::StreamTransformation c);
protected:
virtual int_type overflow(int_type ch = traits_type::eof());
virtual int_type uflow();
virtual int_type underflow();
virtual int_type pbackfail(int_type ch);
virtual int sync();
private:
int GetNextChar();
int m_NextChar; // Buffered character
CryptoPP::StreamTransformationFilter*
m_StreamTransformationFilter;
CryptoPP::FileSource* m_Source;
CryptoPP::FileSink* m_Sink;
}; // class CryptStreamBuffer
CryptStreamBuffer::CryptStreamBuffer(istream encryptedInput,
CryptoPP::StreamTransformation c) :
m_NextChar(traits_type::eof()),
m_StreamTransformationFilter(0),
m_Source(0),
m_Sink(0) {
m_StreamTransformationFilter = new
CryptoPP::StreamTransformationFilter(c);
m_Source = new CryptoPP::FileSource(encryptedInput, false,
m_StreamTransformationFilter);
}
CryptStreamBuffer::CryptStreamBuffer(ostream encryptedOutput,
CryptoPP::StreamTransformation c) :
m_NextChar(traits_type::eof()),
m_StreamTransformationFilter(0),
m_Source(0),
m_Sink(0) {
m_Sink = new CryptoPP::FileSink(encryptedOutput);
m_StreamTransformationFilter = new
CryptoPP::StreamTransformationFilter(c, m_Sink);
}
CryptStreamBuffer::int_type CryptStreamBuffer::overflow(int_type ch) {
return m_StreamTransformationFilter-Put((byte)ch);
}
CryptStreamBuffer::int_type CryptStreamBuffer::uflow() {
int_type result = GetNextChar();
// Reset the buffered character
m_NextChar = traits_type::eof();
return result;
}
CryptStreamBuffer::int_type CryptStreamBuffer::underflow() {
return GetNextChar();
}
CryptStreamBuffer::int_type CryptStreamBuffer::pbackfail(int_type ch)
{
return traits_type::eof();
}
int CryptStreamBuffer::sync() {
if (m_Sink) {
m_StreamTransformationFilter-MessageEnd();
}
}
int CryptStreamBuffer::GetNextChar() {
// If we have a buffered character do nothing
if (m_NextChar != traits_type::eof()) {
return m_NextChar;
}
// If there are no more bytes currently available then pump the
source
if (m_StreamTransformationFilter-MaxRetrievable() == 0
Decrypted AES file is 16 characters short - what am I doing wrong?
Hi,
To answer my own previous question (http://groups.google.com/group/
cryptopp-users/browse_thread/thread/721dbd6fa5992a57) I wrote the code
given at the end of this post.
However it appears that DecryptFile() is not attempting to decrypt the
last 16 bytes (block size) of the encrypted file. Can anybody tell me
what I am doing wrong?
Yours truly,
Tom
// Runtime Includes
#include iostream
// Crypto++ Includes
#include aes.h
#include modes.h // xxx_Mode
#include filters.h// StringSource and
// StreamTransformation
#include files.h
using namespace std;
class CryptStreamBuffer: public std::streambuf {
public:
CryptStreamBuffer(istream encryptedInput,
CryptoPP::StreamTransformation c);
CryptStreamBuffer(ostream encryptedOutput,
CryptoPP::StreamTransformation c);
protected:
virtual int_type overflow(int_type ch = traits_type::eof());
virtual int_type uflow();
virtual int_type underflow();
virtual int_type pbackfail(int_type ch);
virtual int sync();
private:
int GetNextChar();
int m_NextChar; // Buffered character
CryptoPP::StreamTransformationFilter*
m_StreamTransformationFilter;
CryptoPP::FileSource* m_Source;
CryptoPP::FileSink* m_Sink;
}; // class CryptStreamBuffer
CryptStreamBuffer::CryptStreamBuffer(istream encryptedInput,
CryptoPP::StreamTransformation c) :
m_NextChar(traits_type::eof()),
m_StreamTransformationFilter(0),
m_Source(0),
m_Sink(0) {
m_StreamTransformationFilter = new
CryptoPP::StreamTransformationFilter(c);
m_Source = new CryptoPP::FileSource(encryptedInput, false,
m_StreamTransformationFilter);
}
CryptStreamBuffer::CryptStreamBuffer(ostream encryptedOutput,
CryptoPP::StreamTransformation c) :
m_NextChar(traits_type::eof()),
m_StreamTransformationFilter(0),
m_Source(0),
m_Sink(0) {
m_Sink = new CryptoPP::FileSink(encryptedOutput);
m_StreamTransformationFilter = new
CryptoPP::StreamTransformationFilter(c, m_Sink);
}
CryptStreamBuffer::int_type CryptStreamBuffer::overflow(int_type ch) {
return m_StreamTransformationFilter-Put((byte)ch);
}
CryptStreamBuffer::int_type CryptStreamBuffer::uflow() {
int_type result = GetNextChar();
// Reset the buffered character
m_NextChar = traits_type::eof();
return result;
}
CryptStreamBuffer::int_type CryptStreamBuffer::underflow() {
return GetNextChar();
}
CryptStreamBuffer::int_type CryptStreamBuffer::pbackfail(int_type ch)
{
return traits_type::eof();
}
int CryptStreamBuffer::sync() {
if (m_Sink) {
m_StreamTransformationFilter-MessageEnd();
}
}
int CryptStreamBuffer::GetNextChar() {
// If we have a buffered character do nothing
if (m_NextChar != traits_type::eof()) {
return m_NextChar;
}
// If there are no more bytes currently available then pump the
source
if (m_StreamTransformationFilter-MaxRetrievable() == 0) {
m_Source-Pump(1024);
}
// Retrieve the next byte
byte nextByte;
size_t noBytes = m_StreamTransformationFilter-Get(nextByte);
if (0 == noBytes) {
return traits_type::eof();
}
// Buffer up the next character
m_NextChar = nextByte;
return m_NextChar;
}
void InitKey(byte key[]) {
key[0] = -62;
key[1] = 102;
key[2] = 78;
key[3] = 75;
key[4] = -96;
key[5] = 125;
key[6] = 66;
key[7] = 125;
key[8] = -95;
key[9] = -66;
key[10] = 114;
key[11] = 22;
key[12] = 48;
key[13] = 111;
key[14] = -51;
key[15] = 112;
}
void DecryptFile(const char* sourceFileName, const char* destFileName)
{
ifstream ifs(sourceFileName, ios::in | ios::binary);
ofstream ofs(destFileName, ios::out | ios::binary);
byte key[CryptoPP::AES::DEFAULT_KEYLENGTH];
InitKey(key);
CryptoPP::ECB_ModeCryptoPP::AES::Decryption decryptor(key,
sizeof(key));
if (ifs) {
if (ofs) {
CryptStreamBuffer cryptBuf(ifs, decryptor);
std::istream decrypt(cryptBuf);
int c;
while (EOF != (c = decrypt.get())) {
ofs (char)c;
}
ofs.flush();
}
else {
std::cerr Failed to open file ' destFileName
'. endl;
}
}
else {
std::cerr Failed to open file ' sourceFileName '.
endl;
}
}
void EncryptFile(const char* sourceFileName, const char* destFileName)
{
ifstream ifs(sourceFileName, ios::in | ios::binary);
ofstream ofs(destFileName, ios::out | ios::binary);
byte key[CryptoPP::AES::DEFAULT_KEYLENGTH];
InitKey(key);
CryptoPP::ECB_ModeCryptoPP::AES::Encryption encryptor(key,
sizeof(key));
if (ifs) {
if (ofs) {
CryptStreamBuffer cryptBuf(ofs, encryptor);
std::ostream encrypt(cryptBuf);
int c;
while (EOF != (c = ifs.get
Is there a standard mechanism for wrapping an istream around the decryption process?
Hi there, In the application I'm working on I am starting with an encrypted (AES) file and need to present its decrypted contents in the form of a std::istream to a parser component. The encrypted file is potentially too large to be stored entirely in memory and for obvious reasons I don't wish to decrypt it to a temporary plain-text file on the disk. I would have though this was a fairly common problem to solve and before rolling my own I was wondering whether there was something (which I am too unperceptive to find) in the standard API for achieving it or whether there was anybody who had some code (or experience) to share. Thanks, Tom -- 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.
Request for PolynomialOver examples
Hi crypto++-list Does any of you have some source code demonstrating how to use the PolynomialOver class ? Regards, Tom -- Tom Helmer Hansen IT security consultant Roskilde University, Denmark
Re: aes question again
To follow up on this thread - if I wanted to utilize Rijndael in CBC mode with PKCS#5 padding in Cryptopp 5.1, I assume I need to utilize the CBC_ModeRijndael class, but how does one specify padding in this instance? Are you left to implement your own? Was the CBCPaddedEncryptor of 4.2 not carried forward? Or is it assumed to be PKCS#5? What is the mode and padding of the default RijndaelEncryption/Decryption? Many Thanks for any insight... Tom Cowin At 06:22 PM 5/25/2003 +0400, Yusuf Khan-YUK wrote: Thanx Giuliano I am happy to store the file size in the encrypted file and then retrieve it during decryption. On 20 May 2003 at 14:45, Giuliano Bertoletti wrote: Yusuf Khan-YUK wrote: I tried using BlockSize() but my output was still the same. Thats because in my case, the the key size was 16 and BlockSize() also returned 16. There in another mistake in your code, which I did not immediately noticed; when you call: fread(buffer,sizeof(byte), KEYSIZE,fp); you're assuming the input is multiple of KEYSIZE (or better of BlockSize). If that's not true, you implicitly append zeros at the end of your file to allign with the block. When the decryptor reverses the process it has no way of knowing the real file size, and therefore he cannot truncate the file correctly (how does it know how many zeros really belong to the plain-text file ?). You have either to store the plain file length in the encrypted file or to use/implement some padding scheme. Look at previous messages, there's one named questions on data block size? where you can find an example. The version of crypto++ I am using is 4.2, in AESEcnryptor you can only specify the key, you cannot specify the password, or the iv That's because it is only an encryptor. But you can easily convert a password into a key using an hash function (say MD5). In this way you can take variable length input password. The IV can be specified through a CBCPaddedEncryptor for example, which can take the encryptor object (in your case AES) and the IV. -- Giuliano Bertoletti e-Security Manager Intrinsic - Security Monitoring http://www.intrinsic.it COOL-FIRE: la soluzione Firewall per Windows NT/2000 http://www.symbolic.it/Prodotti/cool-fire.html SYMBOLIC S.p.A. Tel: +39 0521 776180 / Fax: +39 0521 776190 Best Regards YUK
RE: Serpent::UncheckedSetKey
Yes, a segfault occurred at the indicated line.
This was using the x86-64 version of gcc.
-Original Message-
From: Wei Dai [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 8:08 PM
To: [EMAIL PROTECTED]
Subject: Re: Serpent::UncheckedSetKey
Thanks, you're right this might be a problem on platforms with 64-bit pointers. (BTW,
did you confirm what would actually happen in this case?)
I checked in a fix to CVS.
On Mon, Mar 24, 2003 at 07:28:30PM -0600, [EMAIL PROTECTED] wrote:
I am definitely not familiar with the Crypto++ library but am trying
to use it as a compiler benchmark.
In the 5.1 codebase, I see the function below (first few lines). Since
the index i is word32 which is unsigned, I would think that
expressions like i-8 and i-5 and i-3 would wrap around to large
positive numbers which is not what is wanted here.
Are there any special procedures to follow for porting
to a 64-bit target?
-- Tom Deneau
void Serpent::Base::UncheckedSetKey(CipherDir direction, const byte
*userKey, unsigned int keylen) {
AssertValidKeyLength(keylen);
word32 *k = m_key;
GetUserKey(LITTLE_ENDIAN_ORDER, k, 8, userKey, keylen);
word32 i,a,b,c,d,e;
if (keylen 32)
k[keylen/4] |= word32(1) ((keylen%4)*8);
k += 8;
word32 t = k[-1];
for (i = 0; i 132; ++i)
k[i] = t = rotlFixed(k[i-8] ^ k[i-5] ^ k[i-3] ^ t ^ 0x9e3779b9 ^ i,
11);
k -= 20;
