Re: [cryptopp-users] Stream cipher Encrypt file having problem
This is clearly a misuse of the mailing list.
Consider that the majority of users in this list are English speakers, you
should also at least translate your comments into English so everyone can
understand you.
Otherwise, such question should go somewhere else rather than this mailing
list.
Anyway, I think the number of bytes you write to is already wrong. Yet,
please note that mailing list doesn't debug, though.
On Fri, Sep 14, 2018, 2:41 AM wrote:
> Hi,everyone. I need your help.
> I had problem when used stream cipher to encrypt and decrypt file.
> I encrypted a file that is 2K, but it would become 3K when I decrypted the
> cipher .
> I think the problem is that I maybe incorrectly use ifstream or ofstream?
> The following is my code.
> #include //包含ChaCha20算法的头文件
> #include//使用cin、cout
> #include //使用AutoSeededRandomPool算法
> #include //使用SecByteBlock
> #include//使用string
> #include//使用ifstream、ofstream
> using namespace std;//std是C++的命名空间
> using namespace CryptoPP;//CryptoPP是Cryptopp库的命名空间
> void EncOrDecFile(const string& srcfile,StreamTransformation& encdec,const
> string& desfile);
> int main()
> {
> ChaCha20::Encryption enc;//定义加密对象
> ChaCha20::Decryption dec;//定义解密对象
> //定义一个随机数发生器，用于产生随机的密钥Key和初始向量IV
> AutoSeededRandomPool prng;
> //动态申请空间以存储接下来生成的密钥key和初始向量iv
> SecByteBlock key(enc.DefaultKeyLength()),iv(enc.DefaultIVLength());
> //产生随机的key和iv
> prng.GenerateBlock(key,key.size());
> prng.GenerateBlock(iv,iv.size());
> //加密和解密准备
> enc.SetKeyWithIV(key,key.size(),iv,iv.size());//设置加密key和iv
> dec.SetKeyWithIV(key,key.size(),iv,iv.size());//设置解密key和iv
> EncOrDecFile("stream_02.cpp",enc,"cipher.txt");
> EncOrDecFile("cipher.txt",dec,"recover.txt");
> return 0;
> }
> //参数srcfile：待加密或解密的文件
> //参数encdec：使用的流密码算法
> //参数desfile：存放加密或解密结果的文件
> void EncOrDecFile(const string& srcfile,StreamTransformation& encdec,const
> string& desfile)
> {//用流密码对象encdec实现对文件srcfile的加密或解密操作，并将操作的结果存放于文件desfile
> ifstream infile(srcfile,ios_base::binary);
> ofstream outfile(desfile,ios_base::binary);
> if(!infile || !outfile)
> {
> cout << "文件打开失败" << endl;
> return ;
> }
> int iread;
> SecByteBlock readstr(1024);
> while(infile)
> {//文件内容读取没有结束
> infile.read((char*)[0],readstr.size());
> iread=infile.gcount();
> iread = iread < readstr.size() ? iread : readstr.size();
> encdec.ProcessString([0],iread);
> outfile.write((char*)[0],readstr.size());
> }
> infile.close();//关闭文件
> outfile.close();//关闭文件
> }
>
> --
> 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.
>
--
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: [cryptopp-users] Website certificate renewal
Seems that recertifying the existing public key is kind of... non-standard practice? What would be the benefit of "key continuity"? On Tue, Jul 24, 2018 at 8:03 AM, Jeffrey Walton wrote: > Hi Everyone, > > We got a renewal notice for the website's certificate. I was going to try > Let's Encrypt and recertify the existing public key. > > The existing cert is from Comodo. We have to ping some folks out of band > for the cert and I want to avoid troubling them. > > The existing public key has not been compromised (to the best of my > knowledge) so I believe we can maintain key continuity. > > Does anyone have any objections? > > 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. > -- Weikeng Chen @ 795 Soda Hall -- 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: [cryptopp-users] Re: IV checker for CryptoPP::CTR_Mode::Encryption()
I think crypto libraries have to assume the developers to have some
familiarity with the cryptography and use it properly.
For example, why do you use AES-CTR? It does not provide integrity guarantee.
Today, AES-GCM is a commonly better option.
On Fri, Jul 6, 2018 at 1:02 AM, 许皓宇 wrote:
> Thanks for your reply:)
> Maybe a warning or auto checker is better for someone who do not know
> details of AES-CTR like me
>
>
> 在 2018年7月6日星期五 UTC+8下午2:38:01，Weikeng Chen写道：
>>
>> The following code in modes.h
>> (https://github.com/weidai11/cryptopp/blob/master/modes.h#L300) shows
>> that IV will become BLOCKSIZE.
>>
>> CipherModeFinalTemplate_CipherHolder(const byte *key, size_t length,
>> const byte *iv)
>> {
>> this->m_cipher = >m_object;
>> this->SetKey(key, length, MakeParameters(Name::IV(),
>> ConstByteArrayParameter(iv, this->m_cipher->BlockSize(;
>> }
>>
>> On Thu, Jul 5, 2018 at 11:35 PM, Jeffrey Walton wrote:
>> >
>> >
>> > On Friday, July 6, 2018 at 2:23:00 AM UTC-4, 许皓宇 wrote:
>> >>
>> >> I've used cryptopp in my project recently, i try to use AES-CTR model
>> >> encryption.
>> >>
>> >> CryptoPP::CTR_Mode::Encryption(const CryptoPP::byte*
>> >> key,
>> >> size_t length, const CryptoPP::byte* iv)
>> >>
>> >> This constructor provide a length check of key but do not check length
>> >> of
>> >> iv
>> >
>> >
>> > For that particular constructor the parameter iv must be BLOCKSIZE
>> > bytes.
>> >
>> > There are other constructors available that takes an ivLength, too.
>> >
>> > Looking at the manual it is not well documented. For example,
>> >
>> > https://www.cryptopp.com/docs/ref/class_cipher_mode_final_template___cipher_holder.html
>> > .
>> >
>> > Let me get some updates added.
>> >
>> > 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-user...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>>
>> Weikeng Chen @ 795 Soda Hall
>
> --
> 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.
--
Weikeng Chen @ 795 Soda Hall
--
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: [cryptopp-users] Re: IV checker for CryptoPP::CTR_Mode::Encryption()
The following code in modes.h
(https://github.com/weidai11/cryptopp/blob/master/modes.h#L300) shows
that IV will become BLOCKSIZE.
CipherModeFinalTemplate_CipherHolder(const byte *key, size_t length,
const byte *iv)
{
this->m_cipher = >m_object;
this->SetKey(key, length, MakeParameters(Name::IV(),
ConstByteArrayParameter(iv, this->m_cipher->BlockSize(;
}
On Thu, Jul 5, 2018 at 11:35 PM, Jeffrey Walton wrote:
>
>
> On Friday, July 6, 2018 at 2:23:00 AM UTC-4, 许皓宇 wrote:
>>
>> I've used cryptopp in my project recently, i try to use AES-CTR model
>> encryption.
>>
>> CryptoPP::CTR_Mode::Encryption(const CryptoPP::byte* key,
>> size_t length, const CryptoPP::byte* iv)
>>
>> This constructor provide a length check of key but do not check length of
>> iv
>
>
> For that particular constructor the parameter iv must be BLOCKSIZE bytes.
>
> There are other constructors available that takes an ivLength, too.
>
> Looking at the manual it is not well documented. For example,
> https://www.cryptopp.com/docs/ref/class_cipher_mode_final_template___cipher_holder.html
> .
>
> Let me get some updates added.
>
> 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.
--
Weikeng Chen @ 795 Soda Hall
--
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: [cryptopp-users] Re: Wiki is down
Is that possible that MediaWiki 1.31 requires PHP7, but the host is not PHP7? See https://www.mediawiki.org/wiki/MediaWiki_1.31 On Sat, Jun 16, 2018 at 3:33 PM, Jeffrey Walton wrote: > > > On Saturday, June 16, 2018 at 4:44:46 PM UTC-4, Jeffrey Walton wrote: >> >> Hi Everyone, >> >> We are in the middle of a wiki upgrade from MediaWiki 1.30 to 1.31. We >> encountered some problems and the wiki is down for the moment. >> >> It appears the wiki tarball is missing some files. We'll get it back up >> as soon as we find the files we need. >> > > We were were not able to upgrade to MediaWiki 1.31. We dropped back to > MediaWiki 1.30 for the time being. > > I'm not sure what we are going to do in the future. > > 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. > -- Weikeng Chen @ 795 Soda Hall -- 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: Report a (not severe) security bug of CryptoPP in ElGamal
What is your plan about the compatibility? 1: new versions can decrypt old versions' ciphertexts 2: old versions can decrypt new versions' ciphertexts, and new versions can decrypt old versions' ciphertexts On Tuesday, May 22, 2018 at 10:33:26 AM UTC-7, Weikeng Chen wrote: > > So as Jeffrey forwarded to the public mail listing, I would like to add a > one-paragraph note for the public: > > Today, mostly ElGamal is used for hybrid encryption, i.e., encrypts > a symmetric key. For this setting, this attack is not useful. > The attack is only useful if you encrypt plain messages. And the > attack can only distinguish some messages, but not recover a message. > > That is also why this is a low-risk security issue. > > > On Tuesday, May 22, 2018 at 3:47:05 AM UTC-7, Jeffrey Walton wrote: >> >> FYI... >> >> -- Forwarded message -- >> From: Weikeng Chen <w...@berkeley.edu> >> Date: Tue, May 22, 2018 at 3:55 AM >> Subject: Report a (not severe) security bug of CryptoPP in ElGamal >> To: nolo...@gmail.com >> >> Hi Jeffrey, >> >> Sorry. This is the only way we can find a maintainer of CryptoPP in >> private, >> which consolidates a responsible disclosure. >> >> CryptoPP uses padding to secure ElGamal. But the padding is not >> sufficient. >> >> In more details, CryptoPP uses a prime-order group with a QR generator >> for ElGamal. That is great! >> (QR means quadratic residue, QNR means quadratic non-residue.) >> But when CryptoPP encodes a message, the message may be encoded into a >> QR or into a QNR, depending on the message and the random pad added to >> the message. >> >> It is possible that given a message m, it has 48% possibility to >> become a QR, and 52% to become a QNR. >> Or, it is also possible that for another message m', it has 52% >> possibility to become a QR, and 48% as a QNR. >> >> There is a *Difference* between different messages, which may lead to >> an attack that guesses the message. >> Because it is easy to determine whether a ciphertext is QR or QNR, and >> it implies whether the padded message is QR or QNR. >> >> We know such explanation is usually not intuitive -- we had very >> terrible experience communicating with PyCryptodome and libgcrypt, so >> far they refuse to fix completely. >> So below is a PoC for CryptoPP, with a preliminary patch: >>https://github.com/weikengchen/attack-on-cryptopp-elgamal >> which the attack abuses the above possibility distribution difference >> to guess the message from the ciphertext. >> >> This security bug is not severe, because, in the real world, people >> use ElGamal mostly to encrypt a symmetric key (i.e., hybrid >> encryption). >> It is secure if ElGamal encrypts a symmetric key. Therefore, we do >> make this repo of the PoC public as it does not lead to a security >> risk to existing systems. >> >> So my report concludes. It is not easy to fix -- because you need to >> change the implementation of ElGamal encryption in CryptoPP to >> proceed, which hurts the compatibility. >> The fix in the patch of that repo is to encode the message into a QR, >> not using padding. >> >> Let me know your idea of what we should do the next. >> >> Weikeng >> > -- 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: Report a (not severe) security bug of CryptoPP in ElGamal
So as Jeffrey forwarded to the public mail listing, I would like to add a one-paragraph note for the public: Today, mostly ElGamal is used for hybrid encryption, i.e., encrypts a symmetric key. For this setting, this attack is not useful. The attack is only useful if you encrypt plain messages. And the attack can only distinguish some messages, but not recover a message. That is also why this is a low-risk security issue. On Tuesday, May 22, 2018 at 3:47:05 AM UTC-7, Jeffrey Walton wrote: > > FYI... > > -- Forwarded message -- > From: Weikeng Chen <w...@berkeley.edu > > Date: Tue, May 22, 2018 at 3:55 AM > Subject: Report a (not severe) security bug of CryptoPP in ElGamal > To: nolo...@gmail.com > > Hi Jeffrey, > > Sorry. This is the only way we can find a maintainer of CryptoPP in > private, > which consolidates a responsible disclosure. > > CryptoPP uses padding to secure ElGamal. But the padding is not > sufficient. > > In more details, CryptoPP uses a prime-order group with a QR generator > for ElGamal. That is great! > (QR means quadratic residue, QNR means quadratic non-residue.) > But when CryptoPP encodes a message, the message may be encoded into a > QR or into a QNR, depending on the message and the random pad added to > the message. > > It is possible that given a message m, it has 48% possibility to > become a QR, and 52% to become a QNR. > Or, it is also possible that for another message m', it has 52% > possibility to become a QR, and 48% as a QNR. > > There is a *Difference* between different messages, which may lead to > an attack that guesses the message. > Because it is easy to determine whether a ciphertext is QR or QNR, and > it implies whether the padded message is QR or QNR. > > We know such explanation is usually not intuitive -- we had very > terrible experience communicating with PyCryptodome and libgcrypt, so > far they refuse to fix completely. > So below is a PoC for CryptoPP, with a preliminary patch: >https://github.com/weikengchen/attack-on-cryptopp-elgamal > which the attack abuses the above possibility distribution difference > to guess the message from the ciphertext. > > This security bug is not severe, because, in the real world, people > use ElGamal mostly to encrypt a symmetric key (i.e., hybrid > encryption). > It is secure if ElGamal encrypts a symmetric key. Therefore, we do > make this repo of the PoC public as it does not lead to a security > risk to existing systems. > > So my report concludes. It is not easy to fix -- because you need to > change the implementation of ElGamal encryption in CryptoPP to > proceed, which hurts the compatibility. > The fix in the patch of that repo is to encode the message into a QR, > not using padding. > > Let me know your idea of what we should do the next. > > Weikeng > -- 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.
