jm + pgp + gpg   6

SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust

Abstract: The SHA-1 hash function was designed in 1995 and has been widely used during two decades. A theoretical collision attack was first proposed in 2004 [WYY05], but due to its high complexity it was only implemented in practice in 2017, using a large GPU cluster [SBK+17]. More recently, an almost practical chosen-prefix collision attack against SHA-1 has been proposed [LP19]. This more powerful attack allows to build colliding messages with two arbitrary prefixes, which is much more threatening for real protocols.

In this paper, we report the first practical implementation of this attack, and its impact on real-world security with a PGP/GnuPG impersonation attack. We managed to significantly reduce the complexity of collisions attack against SHA-1: on an Nvidia GTX 970, identical-prefix collisions can now be computed with a complexity of 261.2261.2 rather than 264.7264.7, and chosen-prefix collisions with a complexity of 263.4263.4 rather than 267.1267.1. When renting cheap GPUs, this translates to a cost of 11k US\$ for a collision, and 45k US\$ for a chosen-prefix collision, within the means of academic researchers. Our actual attack required two months of computations using 900 Nvidia GTX 1060 GPUs (we paid 75k US\$ because GPU prices were higher, and we wasted some time preparing the attack).

Therefore, the same attacks that have been practical on MD5 since 2009 are now practical on SHA-1. In particular, chosen-prefix collisions can break signature schemes and handshake security in secure channel protocols (TLS, SSH). We strongly advise to remove SHA-1 from those type of applications as soon as possible. We exemplify our cryptanalysis by creating a pair of PGP/GnuPG keys with different identities, but colliding SHA-1 certificates. A SHA-1 certification of the first key can therefore be transferred to the second key, leading to a forgery. This proves that SHA-1 signatures now offers virtually no security in practice. The legacy branch of GnuPG still uses SHA-1 by default for identity certifications, but after notifying the authors, the modern branch now rejects SHA-1 signatures (the issue is tracked as CVE-2019-14855).

(Via Tony Finch)
via:fanf  security  sha  sha-1  crypto  hashes  hashing  pgp  gpg  collisions 
7 weeks ago by jm
Attacks against GPG signed APT repositories - Packagecloud Blog

It is a common misconception that simply signing your packages and repository metadata with GPG is enough to create a secure APT repository. This is false. Many of the attacks outlined in the paper and this blog post are effective against GPG-signed APT repositories. GPG signing Debian packages themselves does nothing, as explained below. The easiest way to prevent the attacks covered below is to always serve your APT repository over TLS; no exceptions.

This is excellent research. My faith in GPG sigs on packages is well shaken.
apt  security  debian  packaging  gpg  pgp  packages  dpkg  apt-get  ops 
may 2018 by jm
mozilla/sops: Secrets management stinks, use some sops!
sops is an editor of encrypted files that supports YAML, JSON and BINARY formats and encrypts with AWS KMS and PGP.
secrets  encryption  security  kms  pgp  gpg  editors  configuration 
july 2017 by jm
Stop it with short PGP key IDs!
What happened today? We still don't really know, but it seems we found a first potentially malicious collision — that is, the first "nonacademic" case. Enrico found two keys sharing the 9F6C6333 short ID, apparently belonging to the same person (as would be the case of Asheesh, mentioned above). After contacting Gustavo, though, he does not know about the second — That is, it can be clearly regarded as an impersonation attempt. Besides, what gave away this attempt are the signatures it has: Both keys are signed by what appears to be the same three keys: B29B232A, F2C850CA and 789038F2. Those three keys are not (yet?) uploaded to the keyservers, though... But we can expect them to appear at any point in the future. We don't know who is behind this, or what his purpose is. We just know this looks very evil.
Now, don't panic: Gustavo's key is safe. Same for his certifiers, Marga, Agustín and Maxy. It's just a 32-bit collision. So, in principle, the only parties that could be cheated to trust the attacker are humans, right? Nope.
Enrico tested on the PGP pathfinder & key statistics service, a keyserver that finds trust paths between any two arbitrary keys in the strong set. Surprise: The pathfinder works on the short key IDs, even when supplied full fingerprints. So, it turns out I have three faked trust paths into our impostor.
pgp  gpg  keys  collisions  hashing  security  debian 
june 2016 by jm
Authenticated app packages on Sandstorm with PGP and Keybase
Nice approach to package authentication UX using Keybase/PGP.
When you go to install a package, Sandstorm verifies that the package is correctly signed by the Ed25519 key. It looks for a PGP signature in the metadata, and verifies that the PGP-signed assertion is for the correct app ID and the email address specified in the metadata. It queries the Keybase API to see what accounts the packager has proven ownership of, and lists them with their links on the app install page.
authentication  auth  packages  sandstorm  keybase  pgp  gpg  security 
november 2015 by jm
Nyms Identity Directory
The way that [problems with the PGP bootstrapping] are supposed to be resolved is with an authentication model called the Web of Trust where users sign keys of other users after verifying that they are who they say they are. In theory, if some due diligence is applied in signing other people’s keys and a sufficient number of people participate you’ll be able to follow a short chain of signatures from people you already know and trust to new untrusted keys you download from a key server. In practice this has never worked out very well as it burdens users with the task of manually finding people to sign their keys and even experts find the Web of Trust model difficult to reason about. This also reveals the social graph of certain communities which may place users at risk for their associations. Such signatures also reveal metadata about times and thus places for meetings for key signings.

The Nyms Identity Directory is a replacement for all of this. Keyservers are replaced with an identity directory that gives users full control over publication of their key information and web of trust is replaced with a distributed network of trusted notaries which validate user keys with an email verification protocol.
web-of-trust  directories  nyms  privacy  crypto  identity  trust  pgp  gpg  security  via:ioerror  keyservers  notaries 
august 2014 by jm

Copy this bookmark: