The recently published SWEET32 attack [1] has shown that 64-bit block ciphers should be considered insecure as they as vulnerable to birthday attacks. app-crypt/bcrypt-1.1 encrypts files using a hardcoded Blowfish cipher, which uses a 64-bit block size. Thus I would consider it likely that the plaintext of encrypted files can be recovered partially or fully using birthday attacks, at least if some portion of the plaintext can be guessed or chosen by the attacker (known or chosen plaintext attack). (More critically, the software has not received any maintenance since its 1.1 release in 2002, so upstream is unlikely to release any updates. There might also be other vulnerabilities. For example, from a quick glance at the code there does not appear to be any usage of authentication encryption, which would be considered a novice crypto mistake if the software was released today.) [1] https://www.openssl.org/blog/blog/2016/08/24/sweet32/
If it is already released, is there any reason to keep the bug marked confidential?
I'm a bit unsure about how applicable the attack is to bcrypt as well, given that it seems to be based on using an oracle and amount of traffic similar to CRIME/BEAST in order to get to e.g a session cookie. Is there any other reference for applicability discussed somewhere?
From ${URL}: Cryptographic protocols like TLS, SSH, IPsec, and OpenVPN commonly use block cipher algorithms, such as AES, Triple-DES, and Blowfish, to encrypt data between clients and servers. To use such algorithms, the data is broken into fixed-length chunks, called blocks, and each block is encrypted separately according to a mode of operation. Older block ciphers, such as Triple-DES and Blowfish use a block size of 64 bits, whereas AES uses a block size of 128 bits. It is well-known in the cryptographic community that a short block size makes a block cipher vulnerable to birthday attacks, even if there are no cryptographic attacks against the block cipher itself. We observe that such attacks have now become practical for the common usage of 64-bit block ciphers in popular protocols like TLS and OpenVPN. Still, such ciphers are widely enabled on the Internet. Blowfish is currently the default cipher in OpenVPN, and Triple-DES is supported by nearly all HTTPS web servers, and currently used for roughly 1-2% of HTTPS connections between mainstream browsers and web servers. We show that a network attacker who can monitor a long-lived Triple-DES HTTPS connection between a web browser and a website can recover secure HTTP cookies by capturing around 785 GB of traffic. In our proof-of-concept demo, this attack currently takes less than two days, using malicious Javascript to generate traffic. Keeping a web connection alive for two days may not seem very practical, but it worked easily in the lab. In terms of computational complexity, this attack is comparable to the recent attacks on RC4. We also demonstrate a similar attack on VPNs that use 64-bit ciphers, such as OpenVPN, where long-lived Blowfish connections are the norm. Countermeasures are currently being implemented by browser vendors, OpenSSL, and the OpenVPN team, and we advise users to update to the latest available versions.
I am not aware of any references about how SWEET32 relates to bcrypt file encryption; most of the focus has been on network protocols like TLS, OpenVPN, etc. I doubt there will be any serious analysis by cryptographers as bcrypt is simply such old software. CRIME-like attacks against bcrypt might be possible actually, since bcrypt compresses input files by default before encrypting them. For the SWEET32 attack to be applicable, at least 32 GB of data (usually a bit more) need to be encrypted with the same key. So users who e.g. regularly encrypt backup tarballs using bcrypt could be affected. Other security problems (lack of authenticated encryption, CRIME), if they exist (which is likely), would generally apply to a larger part of the bcrypt userbase. Therefore I would rate them more serious than SWEET32. There is probably not much harm in lifting the confidentiality of this bug, as there is no concrete attack and the abstract attack methods are well-known. I enabled it at first since bcrypt was never mentioned in the public discussion about SWEET32.
(In reply to nomadictype from comment #4) > I am not aware of any references about how SWEET32 relates to bcrypt file > encryption; most of the focus has been on network protocols like TLS, > OpenVPN, etc. > I doubt there will be any serious analysis by cryptographers as bcrypt is > simply such old software. > > CRIME-like attacks against bcrypt might be possible actually, since bcrypt > compresses input files by default before encrypting them. > > For the SWEET32 attack to be applicable, at least 32 GB of data (usually a > bit more) need to be encrypted with the same key. So users who e.g. > regularly encrypt backup tarballs using bcrypt could be affected. Other You mean if the backup tarball is more than 32 GiB? or isn't there any seed used for the KDF in bcrypt?
(In reply to Kristian Fiskerstrand from comment #5) > (In reply to nomadictype from comment #4) > > I am not aware of any references about how SWEET32 relates to bcrypt file > > encryption; most of the focus has been on network protocols like TLS, > > OpenVPN, etc. > > I doubt there will be any serious analysis by cryptographers as bcrypt is > > simply such old software. > > > > CRIME-like attacks against bcrypt might be possible actually, since bcrypt > > compresses input files by default before encrypting them. > > > > For the SWEET32 attack to be applicable, at least 32 GB of data (usually a > > bit more) need to be encrypted with the same key. So users who e.g. > > regularly encrypt backup tarballs using bcrypt could be affected. Other > > You mean if the backup tarball is more than 32 GiB? or isn't there any seed > used for the KDF in bcrypt? And wouldn't the data need to be attacker controlled?
Adding pacho and alonbl to this bug report for comments (am I missing anyone?)
Well, I am not familiar with security stuff at all :( What input do you need from me? If you pretend to get this treecleaned, it has no reverse deps, then, it shouldn't be problematic to do that... but following the regular procedure, as it will be hardmasked for a month, this "secret" about the vulnerability will be lost :|
(In reply to Pacho Ramos from comment #8) > Well, I am not familiar with security stuff at all :( What input do you need > from me? If you pretend to get this treecleaned, it has no reverse deps, > then, it shouldn't be problematic to do that... but following the regular > procedure, as it will be hardmasked for a month, this "secret" about the > vulnerability will be lost :| heh, I added you after a quick (likely too quick) glance through log, and you were the last one to touch it, but it was due to cleanup commit 64160d008be1e50a3b39674449ac64d117e272ce Author: Pacho Ramos <pacho@gentoo.org> Date: Sun Jun 2 10:55:59 2013 +0000 Cleanup due bug #328951 Package-Manager: portage-2.1.12.2/cvs/Linux x86_64 Manifest-Sign-Key: 0xA188FBD4
This is really more of an auditing question, so changing component. What do you say Jason? from my (granted quick) glance at this, I don't believe bcrypt is really affected by this issue unless used over the wire somehow or on large amounts of attacker controlled data. PS! Another reference for this issue: http://blog.cryptographyengineering.com/2016/08/attack-of-week-64-bit-ciphers-in-tls.html
Isn't it the same as a user decides to use DES while 3DES is available? The encryption tool should provide encryption in specific algorithm, block size, key size, encoding etc... Whoever use the tool is responsible to the actual strength.
With regards to seeds / salts / etc.: as far as I was able to see from the source, bcrypt simply expands the typed password into a key, mutates it in a deterministic way (mutateKey in keys.c) to get a second key and then uses the two keys for blowfish encryption. No randomness is involved (unless I missed it), so the same password should always result in the same encryption key. From what I found, the only part of the whole program that uses randomness is the function that overwrites the original file with random data (deletefile in rwfile.c). It uses a non-cryptographic PRNG, but that's okay for the purpose of that function. The source of bcrypt itself is not too talkative with comments about the general algorithms and file formats used, but I found some discussion here: http://insecurety.net/?p=381 The attacker indeed needs to be able to predict, know or control parts of the plaintext, but that is usually not too difficult. Sticking with the tarball backup example, the tar file headers or gzip header could be predictable, and perhaps the backup includes some known system files or default configuration files. In addition, many file types start with a predictable file header.
(In reply to Alon Bar-Lev from comment #11) > Isn't it the same as a user decides to use DES while 3DES is available? > The encryption tool should provide encryption in specific algorithm, block > size, key size, encoding etc... Whoever use the tool is responsible to the > actual strength. Ok, I think this boils down to whether we want to keep such a specific tool in stable tree irrespective of whether this particular attack is effective against it or not if upstream is dead. If there is a question of security and no reverse deps, maybe we should just treeclean it?
Lifting security group restriction, this issue is discussing a public paper
(In reply to Kristian Fiskerstrand from comment #13) > (In reply to Alon Bar-Lev from comment #11) > > Isn't it the same as a user decides to use DES while 3DES is available? > > The encryption tool should provide encryption in specific algorithm, block > > size, key size, encoding etc... Whoever use the tool is responsible to the > > actual strength. > > Ok, I think this boils down to whether we want to keep such a specific tool > in stable tree irrespective of whether this particular attack is effective > against it or not if upstream is dead. If there is a question of security > and no reverse deps, maybe we should just treeclean it? I am totally fine with removing it.
(In reply to Alon Bar-Lev from comment #15) > (In reply to Kristian Fiskerstrand from comment #13) > > (In reply to Alon Bar-Lev from comment #11) > > > Isn't it the same as a user decides to use DES while 3DES is available? > > > The encryption tool should provide encryption in specific algorithm, block > > > size, key size, encoding etc... Whoever use the tool is responsible to the > > > actual strength. > > > > Ok, I think this boils down to whether we want to keep such a specific tool > > in stable tree irrespective of whether this particular attack is effective > > against it or not if upstream is dead. If there is a question of security > > and no reverse deps, maybe we should just treeclean it? > > I am totally fine with removing it. Will you do the honor of last riting it? I expect treecleaners is busy as it is so we can likely handle this within the project.
(In reply to Kristian Fiskerstrand from comment #16) > Will you do the honor of last riting it? I expect treecleaners is busy as it > is so we can likely handle this within the project. yes, will be able to do this next week, have no access this week.
(In reply to Alon Bar-Lev from comment #17) > (In reply to Kristian Fiskerstrand from comment #16) > > Will you do the honor of last riting it? I expect treecleaners is busy as it > > is so we can likely handle this within the project. > > yes, will be able to do this next week, have no access this week. Thanks :)
Thanks (with the treecleaners hat ;) Anyway I CC us for the case you are finally too busy to prevent this is forgotten
(In reply to Alon Bar-Lev from comment #17) > (In reply to Kristian Fiskerstrand from comment #16) > > Will you do the honor of last riting it? I expect treecleaners is busy as it > > is so we can likely handle this within the project. > > yes, will be able to do this next week, have no access this week. Done
This utility actually has worse issues than birthday attacks... As far as I can tell, it uses the infamous ECB mode, which leaks repeated plaintext blocks. I can only hope nobody is using this to protect important information!
This bug report can be closed once last rite period is up. currently masked with # Alon Bar-Lev <alonbl@gentoo.org (09 Sep 2016) # Weak cryptography (bug #592114) # Package will be removed from Gentoo in 30 days. app-crypt/bcrypt
Removed from tree.
