dkg is currently certified at Master level.

Name: Daniel Kahn Gillmor
Member since: 2009-01-05 21:31:28
Last Login: 2009-01-06 19:54:49

FOAF RDF Share This

Homepage: http://cmrg.fifthhorseman.net/wiki/dkg

Notes:

I'm a free software developer and technology advisor for activist groups, educational groups, and non-profits. I'm a debian maintainer, and in the queue toward becoming a debian developer (though i have no illusions about that being a speedy process). I contribute to a range of projects, but my focus these days is on sorting out cryptographic infrastructure, and PKI in particular. I'd like to see the global network be a place that encourages end-to-end communication (where people are both producers and consumers of culture, ideas, and tools), rather than a system that traps people into mechanisms of centralized control. Without a reasonable *and* intuitive PKI, the hope of empowering the end user to be in full control of their communication will fade in the face of the power of the entities that control the networks themselves. Because this goal is for wide-spread user adoption, i also have a strong interest in usability, though my skills need work there. Good usability is actually much harder than good cryptography, i think. Some interesting projects that i'm a significant contributor to:

  • monkeysphere, an OpenPGP-based PKI for SSH
  • debirf, a project to run a full debian distribution entirely from RAM
I do minor contributions and security audits on a range of tools, including GnuTLS, Trac and OpenSSH. I maintain about a half-dozen packages for debian. My OpenPGP key is 0xD21739E9 (fingerprint .0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9)

Projects

Recent blog entries by dkg

Syndication: RSS 2.0

Bootable grub USB stick (EFI and BIOS for Intel)

I'm using grub version 2.02~beta2-2.

I want to make a USB stick that's capable of booting Intel architecture EFI machines, both 64-bit (x86_64) and 32-bit (ia32). I'm starting from a USB stick which is attached to a running debian system as /dev/sdX. I have nothing that i care about on that USB stick, and all data on it will be destroyed by this process.

I'm also going to try to make it bootable for traditional Intel BIOS machines, since that seems handy.

I'm documenting what I did here, in case it's useful to other people.

Set up the USB stick's partition table:

parted /dev/sdX -- mktable gpt
parted /dev/sdX -- mkpart biosgrub fat32 1MiB 4MiB
parted /dev/sdX -- mkpart efi fat32 4MiB -1
parted /dev/sdX -- set 1 bios_grub on
parted /dev/sdX -- set 2 esp on
After this, my 1GiB USB stick looks like:
0 root@foo:~# parted /dev/sdX -- print
Model:  USB FLASH DRIVE (scsi)
Disk /dev/sdX: 1032MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name      Flags
 1      1049kB  4194kB  3146kB  fat32        biosgrub  bios_grub
 2      4194kB  1031MB  1027MB               efi       boot, esp

0 root@foo:~# 
make a filesystem and mount it temporarily at /mnt:
mkfs -t vfat -n GRUB /dev/sdX2
mount /dev/sdX2 /mnt
ensure we have the binaries needed, and add three grub targets for the different platforms:
apt install grub-efi-ia32-bin grub-efi-amd64-bin grub-pc-bin grub2-common

grub-install --removable --no-nvram --no-uefi-secure-boot \
     --efi-directory=/mnt --boot-directory=/mnt \
     --target=i386-efi

grub-install --removable --no-nvram --no-uefi-secure-boot \
     --efi-directory=/mnt --boot-directory=/mnt \
     --target=x86_64-efi

grub-install --removable --boot-directory=/mnt \
     --target=i386-pc /dev/sdX
At this point, you should add anything else you want to /mnt here! For example: And don't forget to cleanup:
umount /mnt
sync

Tags: bios, efi, grub, tip

Syndicated 2015-03-16 23:12:00 from Weblogs for dkg

a10n for l10n

The abbreviated title above means "Appreciation for Localization" :)

I wanted to say a word of thanks for the awesome work done by debian localization teams. I speak English, and my other language skills are weak. I'm lucky: most software I use is written by default in a language that I can already understand.

The debian localization teams do great work in making sure that packages in debian gets translated into many other languages, so that many more people around the world can take advantage of free software.

I was reminded of this work recently (again) with the great patches submitted to GnuPG and related packages. The changes were made by many different people, and coordinated with the debian GnuPG packaging team by David Prévot.

This work doesn't just help debian and its users. These localizations make their way back upstream to the original projects, which in turn are available to many other people.

If you use debian, and you speak a language other than english, and you want to give back to the community, please consider joining one of the localization teams. They are a great way to help out our project's top priorities: our users and free software.

Thank you to all the localizers!

(this post was inspired by gregoa's debian advent calendar. i won't be posting public words of thanks as frequently or as diligently as he does, any more than i'll be fixing the number of RC bugs that he fixes. This are just two of the ways that gregoa consistently leads the community by example. He's an inspiration, even if living up to his example is a daunting challenge.)

Syndicated 2014-12-12 23:00:00 from Weblogs for dkg

GnuPG 2.1.0 in debian experimental

Today, i uploaded GnuPG 2.1.0 into debian's experimental suite. It's built for amd64 and i386 and powerpc already. You can monitor its progress on the buildds to see when it's available for your architecture.

Changes

GnuPG 2.1 offers many new and interesting features, but one of the most important changes is the introduction of elliptic curve crypto (ECC). While GnuPG 2.1 discourages the creation of ECC keys by default, it's important that we have the ability to verify ECC signatures and to encrypt to ECC keys if other people are using this tech. It seems likely, for example, that Google's End-To-End Chrome OpenPGP extension will use ECC. Users who don't have this capability available won't be able to communicate with End-To-End users.

There are many other architectural changes, including a move to more daemonized interactions with the outside world, including using dirmngr to talk to the keyservers, and relying more heavily on gpg-agent for secret key access. The gpg-agent change is a welcome one -- the agent now holds the secret key material entirely and never releases it -- as of 2.1 gpg2 never has any asymmetric secret key material in its process space at all.

One other nice change for those of us with large keyrings is the new keybox format for public key material. This provides much faster indexed access to the public keyring.

I've been using GnuPG 2.1.0 betas regularly for the last month, and i think that for the most part, they're ready for regular use.

Timing for debian

The timing between the debian freeze and the GnuPG upstream is unfortunate, but i don't think i'm prepared to push for this as a jessie transition yet, without more backup. I'm talking to other members of the GnuPG packaging team to see if they think this is worth even bringing to the attention of the release team, but i'm not pursuing it at the moment.

If you really want to see this in debian jessie, please install the experimental package and let me know how it works for you.

Long term migration concerns

GnuPG upstream is now maintaining three branches concurrently: modern (2.1.x), stable (2.0.x), and classic (1.4.x). I think this is stretches the GnuPG upstream development team too thin, and we should do what we can to help them transition to supporting fewer releases concurrently.

In the long-term, I'd ultimately like to see gnupg 2.1.x to replace all use of gpg 1.4.x and gpg 2.0.x in debian, but unlikely to to happen right now.

In particular, the following two bugs make it impossible to use my current, common monkeysphere workflow:

And GnuPG 2.1.0 drops support for the older, known-weak OpenPGPv3 key formats. This is an important step for simplification, but there are a few people who probably still need to use v3 keys for obscure/janky reasons, or have data encrypted to a v3 key that they need to be able to decrypt. Those people will want to have GnuPG 1.4 around.

Call for testing

Anyway, if you use debian testing or unstable, and you are interested in these features, i invite you to install `gnupg2` and its friends from experimental. If you want to be sensibly conservative, i recommend backing up `~/.gnupg` before trying to use it:

cp -aT .gnupg .gnupg.bak
sudo apt install -t experimental gnupg2 gnupg-agent dirmngr gpgsm gpgv2 scdaemon
If you find issues, please file them via the debian BTS as usual. I (or other members of the pkg-gnupg team) will help you triage them to upstream as needed.

Tags: ecc, experimental, gnupg

Syndicated 2014-11-06 23:27:00 from Weblogs for dkg

OTR key replacement (heartbleed)

I'm replacing my OTR key for XMPP because of heartbleed (see below).

If the plain ASCII text below is mangled beyond verification, you can retrieve a copy of it from my web site that should be able to be verified.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

OTR Key Replacement for XMPP dkg@jabber.org
===========================================
Date: 2014-04-14

My main XMPP account is dkg@jabber.org.

I prefer OTR [0] conversations when using XMPP for private
discussions.

I was using irssi to connect to XMPP servers, and irssi relies on
OpenSSL for the TLS connections.  I was using it with versions of
OpenSSL that were vulnerable to the "Heartbleed" attack [1].  It's
possible that my OTR long-term secret key was leaked via this attack.

As a result, I'm changing my OTR key for this account.

The new, correct OTR fingerprint for the XMPP account at dkg@jabber.org is:

  F8953C5D 48ABABA2 F48EE99C D6550A78 A91EF63D

Thanks for taking the time to verify your peers' fingerprints.  Secure
communication is important not only to protect yourself, but also to
protect your friends, their friends and so on.

Happy Hacking,

  --dkg  (Daniel Kahn Gillmor)

Notes:

[0] OTR: https://otr.cypherpunks.ca/
[1] Heartbleed: http://heartbleed.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJTTBF+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcYwkQAKLzEnTV1lrK6YrhdvRnuYnh
Bh9Ad2ZY44RQmN+STMEnCJ4OWbn5qx/NrziNVUZN6JddrEvYUOxME6K0mGHdY2KR
yjLYudsBuSMZQ+5crZkE8rjBL8vDj8Dbn3mHyT8bAbB9cmASESeQMu96vni15ePd
2sB7iBofee9YAoiewI+xRvjo2aRX8nbFSykoIusgnYG2qwo2qPaBVOjmoBPB5YRI
PkN0/hAh11Ky0qQ/GUROytp/BMJXZx2rea2xHs0mplZLqJrX400u1Bawllgz3gfV
qQKKNc3st6iHf3F6p6Z0db9NRq+AJ24fTJNcQ+t07vMZHCWM+hTelofvDyBhqG/r
l8e4gdSh/zWTR/7TR3ZYLCiZzU0uYNd0rE3CcxDbnGTUS1ZxooykWBNIPJMl1DUE
zzcrQleLS5tna1b9la3rJWtFIATyO4dvUXXa9wU3c3+Wr60cSXbsK5OCct2KmiWY
fJme0bpM5m1j7B8QwLzKqy/+YgOOJ05QDVbBZwJn1B7rvUYmb968yLQUqO5Q87L4
GvPB1yY+2bLLF2oFMJJzFmhKuAflslRXyKcAhTmtKZY+hUpxoWuVa1qLU3bQCUSE
MlC4Hv6vaq14BEYLeopoSb7THsIcUdRjho+WEKPkryj6aVZM5WnIGIS/4QtYvWpk
3UsXFdVZGfE9rfCOLf0F
=BGa1
-----END PGP SIGNATURE-----

Syndicated 2014-04-14 18:43:00 from Weblogs for dkg

Inline-PGP considered harmful

We changed the default PGP signatures generated by enigmail in debian from Inline PGP to PGP/MIME last year, and the experiment has gone well enough that we're now using it in jessie and wheezy (where it arrived as part of a security update to make the extension work with the security-updated icedove package).

After having several people poke me in different contexts about why inline cleartext PGP signatures are a bad idea, i got sufficiently tired of repeating myself, and finally documented some of the problems explicitly.

The report includes a demonstration of a content-tampering attack that changes the meaning of a signed inline-PGP message without breaking the signature, which i first worked out on the notmuch mailing list, but hadn't gotten around to demonstrating until recently.

The attack is demonstrated against clearsigned messages, but also works against inline encrypted messages (but is harder to demonstrate since a demonstration would require sharing secret key material for the decryption step).

Please don't generate Inline-PGP messages. And if you must parse and accept them, please consider carefully the risks you expose your users to and think about ways to mitigate the problems.

Tags: charset, inline-pgp, openpgp, security

Syndicated 2014-02-24 02:09:00 from Weblogs for dkg

79 older entries...

 

dkg certified others as follows:

  • dkg certified skx as Master

Others have certified dkg as follows:

  • skx certified dkg as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page