# Recent blog entries for jas

Dice Random Numbers

Generating data with entropy, or random number generation (RNG), is a well-known difficult problem. Many crypto algorithms and protocols assumes random data is available. There are many implementations out there, including /dev/random in the BSD and Linux kernels and API calls in crypto libraries such as GnuTLS or OpenSSL. How they work can be understood by reading the source code. The quality of the data depends on actual hardware and what entropy sources were available — the RNG implementation itself is deterministic, it merely convert data with supposed entropy from a set of data sources and then generate an output stream.

In some situations, like on virtualized environments or on small embedded systems, it is hard to find sources of sufficient quantity. Rarely are there any lower-bound estimates on how much entropy there is in the data you get. You can improve the RNG issue by using a separate hardware RNG, but there is deployment complexity in that, and from a theoretical point of view, the problem of trusting that you get good random data merely moved from one system to another. (There is more to say about hardware RNGs, I’ll save that for another day.)

For some purposes, the available solutions does not inspire enough confidence in me because of the high complexity. Complexity is often the enemy of security. In crypto discussions I have said, only half-jokingly, that about the only RNG process that I would trust is one that I can explain in simple words and implement myself with the help of pen and paper. Normally I use the example of rolling a normal six-sided dice (a D6) several times. I have been thinking about this process in more detail lately, and felt it was time to write it down, regardless of how silly it may seem.

A dice with six sides produces a random number between 1 and 6. It is relatively straight forward to intuitively convinced yourself that it is not clearly biased: inspect that it looks symmetric and do some trial rolls. By repeatedly rolling the dice, you can generate how much data you need, time permitting.

I do not understand enough thermodynamics physics to know how to estimate the amount of entropy of a physical process, so I need to resort to intuitive arguments. It would be easy to just assume that a dice produces 3 bits of entropy, because 2^3=6 which matches the number of possible outcomes. At least I find it easy to convince myself that 3 bits is the upper bound. I suspect that most dice have some form of defect, though, which leads to a very small bias that could be found with a large number of rolls. Thus I would propose that the amount of entropy of most D6’s are slightly below 3 bits on average. Further, to establish a lower bound, and intuitively, it seems easy to believe that if the entropy of particular D6 would be closer to 2 bits than to 3 bits, this would be noticeable fairly quickly by trial rolls. That assumes the dice does not have complex logic and machinery in it that would hide the patterns. With the tinfoil hat on, consider a dice with a power source and mechanics in it that allowed it to decide which number it would land on: it could generate seamingly-looking random pattern that still contained 0 bits of entropy. For example, suppose a D6 is built to produce the pattern 4, 1, 4, 2, 1, 3, 5, 6, 2, 3, 1, 3, 6, 3, 5, 6, 4, … this would mean it produces 0 bits of entropy (compare the numbers with the decimals of sqrt(2)). Other factors may also influence the amount of entropy in the output, consider if you roll the dice by just dropping straight down from 1cm/1inch above the table. With this discussion as background, and for simplicity, going forward, I will assume that my D6 produces 3 bits of entropy on every roll.

We need to figure out how many times we need to roll it. I usually find myself needing a 128-bit random number (16 bytes). Crypto algorithms and protocols typically use power-of-2 data sizes. 64 bits of entropy results in brute-force attacks requiring about 2^64 tests, and for many operations, this is feasible with today’s computing power. Performing 2^128 operations does not seem possible with today’s technology. To produce 128 bits of entropy using a D6 that produces 3 bits of entropy per roll, you need to perform ceil(128/3)=43 rolls.

We also need to design an algorithm to convert the D6 output into the resulting 128-bit random number. While it would be nice from a theoretical point of view to let each and every bit of the D6 output influence each and every bit of the 128-bit random number, this becomes difficult to do with pen and paper. For simplicity, my process will be to write the binary representation of the D6 output on paper in 3-bit chunks and then read it up as 8-bit chunks. After 8 rolls, there are 24 bits available, which can be read up as 3 distinct 8-bit numbers. So let’s do this for the D6 outputs of 3, 6, 1, 1, 2, 5, 4, 1:

```3   6   1   1   2   5   4   1
011 111 001 001 010 101 010 001
01111100 10010101 01010001
124 0x7C 149 0x95 81 0x51
```

After 8 rolls, we have generated the 3 byte hex string “7C9551″. I repeat the process 5 more times, concatenating the strings, resulting in a hex string with 15 bytes of data. To get the last byte, I only need to roll the D6 three more times, where the two high bits of the last roll is used and the lowest bit is discarded. Let’s say the last D6 outputs were 4, 2, 3, this would result in:

```4   2   3
100 010 011
10001001
137 0x89
```

So the 16 bytes of random data is “7C9551..89″ with “..” replaced by the 5 pieces of 3-byte chunks of data.

So what’s the next step? Depends on what you want to use the random data for. For some purposes, such as generating a high-quality 128-bit AES key, I would be done. The key is right there. To generate a high-quality ECC private key, you need to generate somewhat more randomness (matching the ECC curve size) and do a couple of EC operations. To generate a high-quality RSA private key, unfortunately you will need much more randomness, at the point where it makes more sense to implement a PRNG seeded with a strong 128-bit seed generated using this process. The latter approach is the general solution: generate 128 bits of data using the dice approach, and then seed a CSPRNG of your choice to get large number of data quickly. These steps are somewhat technical, and you lose the pen-and-paper properties, but code to implement these parts are easier to verify compared to verifying that you get good quality entropy out of your RNG implementation.

Syndicated 2014-11-11 23:36:02 from Simon Josefsson's blog

The Case for Short OpenPGP Key Validity Periods

After I moved to a new OpenPGP key (see key transition statement) I have received comments about the short life length of my new key. When I created the key (see my GnuPG setup) I set it to expire after 100 days. Some people assumed that I would have to create a new key then, and therefore wondered what value there is to sign a key that will expire in two months. It doesn’t work like that, and below I will explain how OpenPGP key expiration works; how to extend the expiration time of your key; and argue why having a relatively short validity period can be a good thing.

The OpenPGP message format has a sub-packet called the Key Expiration Time, quoting the RFC:

```5.2.3.6. Key Expiration Time

(4-octet time field)

The validity period of the key.  This is the number of seconds after
the key creation time that the key expires.  If this is not present
or has a value of zero, the key never expires.  This is found only on
a self-signature.
```

You can print the sub-packets in your OpenPGP key with `gpg --list-packets`. See below an output for my key, and notice the “created 1403464490″ (which is Unix time for 2014-06-22 21:14:50) and the “subpkt 9 len 4 (key expires after 100d0h0m)” which adds up to an expiration on 2014-09-26. Don’t confuse the creation time of the key (“created 1403464321″) with when the signature was created (“created 1403464490″).

```jas@latte:~\$ gpg --export 54265e8c | gpg --list-packets |head -20
:public key packet:
version 4, algo 1, created 1403464321, expires 0
pkey[0]: [3744 bits]
pkey[1]: [17 bits]
:user ID packet: "Simon Josefsson "
:signature packet: algo 1, keyid 0664A76954265E8C
version 4, created 1403464490, md5len 0, sigclass 0x13
digest algo 10, begin of digest be 8e
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 9 len 4 (key expires after 100d0h0m)
hashed subpkt 11 len 7 (pref-sym-algos: 9 8 7 13 12 11 10)
hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (key server preferences: 80)
hashed subpkt 2 len 4 (sig created 2014-06-22)
hashed subpkt 25 len 1 (primary user ID)
subpkt 16 len 8 (issuer key ID 0664A76954265E8C)
data: [3743 bits]
:signature packet: algo 1, keyid EDA21E94B565716F
version 4, created 1403466403, md5len 0, sigclass 0x10
jas@latte:~\$
```

So the key will simply stop being valid after that time? No. It is possible to update the key expiration time value, re-sign the key, and distribute the key to people you communicate with directly or indirectly to OpenPGP keyservers. Since that date is a couple of weeks away, now felt like the perfect opportunity to go through the exercise of taking out my offline master key and boot from a Debian LiveCD and extend its expiry time. See my earlier writeup for LiveCD and USB stick conventions.

```user@debian:~\$ export GNUPGHOME=/media/FA21-AE97/gnupghome
user@debian:~\$ gpg --edit-key 54265e8c
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  3744R/54265E8C  created: 2014-06-22  expires: 2014-09-30  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/32F8119D  created: 2014-06-22  expires: 2014-09-30  usage: S
sub  2048R/78ECD86B  created: 2014-06-22  expires: 2014-09-30  usage: E
sub  2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 150
Key expires at Fri 23 Jan 2015 02:47:48 PM UTC
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 54265E8C, created 2014-06-22

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/32F8119D  created: 2014-06-22  expires: 2014-09-30  usage: S
sub  2048R/78ECD86B  created: 2014-06-22  expires: 2014-09-30  usage: E
sub  2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> key 1

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub* 2048R/32F8119D  created: 2014-06-22  expires: 2014-09-30  usage: S
sub  2048R/78ECD86B  created: 2014-06-22  expires: 2014-09-30  usage: E
sub  2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 150
Key expires at Fri 23 Jan 2015 02:48:05 PM UTC
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 54265E8C, created 2014-06-22

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub* 2048R/32F8119D  created: 2014-06-22  expires: 2015-01-23  usage: S
sub  2048R/78ECD86B  created: 2014-06-22  expires: 2014-09-30  usage: E
sub  2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> key 2

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub* 2048R/32F8119D  created: 2014-06-22  expires: 2015-01-23  usage: S
sub* 2048R/78ECD86B  created: 2014-06-22  expires: 2014-09-30  usage: E
sub  2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> key 1

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/32F8119D  created: 2014-06-22  expires: 2015-01-23  usage: S
sub* 2048R/78ECD86B  created: 2014-06-22  expires: 2014-09-30  usage: E
sub  2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 150
Key expires at Fri 23 Jan 2015 02:48:14 PM UTC
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 54265E8C, created 2014-06-22

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/32F8119D  created: 2014-06-22  expires: 2015-01-23  usage: S
sub* 2048R/78ECD86B  created: 2014-06-22  expires: 2015-01-23  usage: E
sub  2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> key 3

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/32F8119D  created: 2014-06-22  expires: 2015-01-23  usage: S
sub* 2048R/78ECD86B  created: 2014-06-22  expires: 2015-01-23  usage: E
sub* 2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> key 2

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/32F8119D  created: 2014-06-22  expires: 2015-01-23  usage: S
sub  2048R/78ECD86B  created: 2014-06-22  expires: 2015-01-23  usage: E
sub* 2048R/36BA8F9B  created: 2014-06-22  expires: 2014-09-30  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 150
Key expires at Fri 23 Jan 2015 02:48:23 PM UTC
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 54265E8C, created 2014-06-22

pub  3744R/54265E8C  created: 2014-06-22  expires: 2015-01-23  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/32F8119D  created: 2014-06-22  expires: 2015-01-23  usage: S
sub  2048R/78ECD86B  created: 2014-06-22  expires: 2015-01-23  usage: E
sub* 2048R/36BA8F9B  created: 2014-06-22  expires: 2015-01-23  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  Simon Josefsson

gpg> save
user@debian:~\$ gpg -a --export 54265e8c > /media/KINGSTON/updated-key.txt
user@debian:~\$
```

I remove the “transport” USB stick from the “offline” computer, and back on my laptop I can inspect the new updated key. Let’s use the same command as before. The key creation time is the same (“created 1403464321″), of course, but the signature packet has a new time (“created 1409064478″) since it was signed now. Notice “created 1409064478″ and “subpkt 9 len 4 (key expires after 214d19h35m)”. The expiration time is computed based on when the key was generated, not when the signature packet was generated. You may want to double-check the pref-sym-algos, pref-hash-algos and other sub-packets so that you don’t accidentally change anything else. (Btw, re-signing your key is also how you would modify those preferences over time.)

```jas@latte:~\$ cat /media/KINGSTON/updated-key.txt |gpg --list-packets | head -20
:public key packet:
version 4, algo 1, created 1403464321, expires 0
pkey[0]: [3744 bits]
pkey[1]: [17 bits]
:user ID packet: "Simon Josefsson "
:signature packet: algo 1, keyid 0664A76954265E8C
version 4, created 1409064478, md5len 0, sigclass 0x13
digest algo 10, begin of digest 5c b2
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 7 (pref-sym-algos: 9 8 7 13 12 11 10)
hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (key server preferences: 80)
hashed subpkt 25 len 1 (primary user ID)
hashed subpkt 2 len 4 (sig created 2014-08-26)
hashed subpkt 9 len 4 (key expires after 214d19h35m)
subpkt 16 len 8 (issuer key ID 0664A76954265E8C)
data: [3744 bits]
:user ID packet: "Simon Josefsson "
:signature packet: algo 1, keyid 0664A76954265E8C
jas@latte:~\$
```

Being happy with the new key, I import it and send it to key servers out there.

```jas@latte:~\$ gpg --import /media/KINGSTON/updated-key.txt
gpg: key 54265E8C: "Simon Josefsson " 5 new signatures
gpg: Total number processed: 1
gpg:         new signatures: 5
jas@latte:~\$ gpg --send-keys 54265e8c
gpg: sending key 54265E8C to hkp server keys.gnupg.net
jas@latte:~\$ gpg --keyserver keyring.debian.org  --send-keys 54265e8c
gpg: sending key 54265E8C to hkp server keyring.debian.org
jas@latte:~\$
```

Finally: why go through this hassle, rather than set the key to expire in 50 years? Some reasons for this are:

1. I don’t trust myselt to keep track of a private key (or revocation cert) for 50 years.
2. I want people to notice my revocation certificate as quickly as possible.
3. I want people to notice other changes to my key (e.g., cipher preferences) as quickly as possible.

Let’s look into the first reason a bit more. What would happen if I lose both the master key and the revocation cert, for a key that’s valid 50 years? I would start from scratch and create a new key that I upload to keyservers. Then there would be two keys out there that are valid and identify me, and both will have a set of signatures on it. None of them will be revoked. If I happen to lose the new key again, there will be three valid keys out there with signatures on it. You may argue that this shouldn’t be a problem, and that nobody should use any other key than the latest one I want to be used, but that’s a technical argument — and at this point we have moved into usability, and that’s a trickier area. Having users select which out of a couple of apparently all valid keys that exist for me is simply not going to work well.

The second is more subtle, but considerably more important. If people retrieve my key from keyservers today, and it expires in 50 years, there will be no need to refresh it from key servers. If for some reason I have to publish my revocation certificate, there will be people that won’t see it. If instead I set a short validity period, people will have to refresh my key once in a while, and will then either get an updated expiration time, or will get the revocation certificate. This amounts to a CRL/OCSP-like model.

The third is similar to the second, but deserves to be mentioned on its own. Because the cipher preferences are expressed (and signed) in my key, and that ciphers come and go, I would expect that I will modify those during the life-time of my long-term key. If I have a long validity period of my key, people would not refresh it from key servers, and would encrypt messages to me with ciphers I may no longer want to be used.

The downside of having a short validity period is that I have to do slightly more work to get out the offline master key once in a while (which I have to once in a while anyway because I’m signing other peoples keys) and that others need to refresh my key from the key servers. Can anyone identify other disadvantages? Also, having to explain why I’m using a short validity period used to be a downside, but with this writeup posted that won’t be the case any more.

Syndicated 2014-08-26 18:11:27 from Simon Josefsson's blog

Wifi on S3 with Replicant

I’m using Replicant on my main phone. As I’ve written before, I didn’t get Wifi to work. The other day leth in #replicant pointed me towards a CyanogenMod discussion about a similar issue. The fix does indeed work, and allowed me to connect to wifi networks and to setup my phone for Internet sharing. Digging deeper, I found a CM Jira issue about it, and ultimately a code commit. It seems the issue is that more recent S3′s comes with a Murata Wifi chipset that uses MAC addresses not known back in the Android 4.2 (CM-10.1.3 and Replicant-4.2) days. Pulling in the latest fixes for macloader.cpp solves this problem for me, although I still need to load the non-free firmware images that I get from CM-10.1.3. I’ve created a pull request fixing macloader.cpp for Replicant 4.2 if someone else is curious about the details. You have to rebuild your OS with the patch for things to work (if you don’t want to, the workaround using `/data/.cid.info` works fine), and install some firmware blobs as below.

```adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_apsta.bin_b1 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_apsta.bin_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b0 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b1 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b0 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b1 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b0 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b1 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_murata /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_murata_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_semcosh /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_murata /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_murata_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_semcosh /system/vendor/firmware/
```

Syndicated 2014-08-10 18:02:37 from Simon Josefsson's blog

Replicant 4.2 0002 and NFC on I9300

During my vacation the Replicant project released version 4.2-0002 as a minor update to their initial 4.2 release. I didn’t anticipate any significant differences, so I followed the installation instructions but instead of “wipe data/factory reset” I chose “wipe cache partition” and rebooted. Everything appeared to work fine, but I soon discovered that NFC was not working. Using `adb logcat` I could get some error messages:

```E/NFC-HCI ( 7022): HCI Timeout - Exception raised - Force restart of NFC service
F/libc    ( 7022): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 7046 (message)
I/DEBUG   ( 1900): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   ( 1900): Build fingerprint: 'samsung/m0xx/m0:4.1.1/JRO03C/I9300XXDLIB:user/release-keys'
I/DEBUG   ( 1900): Revision: '12'
I/DEBUG   ( 1900): pid: 7022, tid: 7046, name: message  >>> com.android.nfc
The phone would loop trying to start NFC and having the NFC sub-system die over and over.  Talking on #replicant channel, paulk quickly realized and fixed the bug.  I had to rebuild the images to get things to work, so I took the time to create a new virtual machine based on Debian 7.5 for building Replicant on.  As a side note, the only thing not covered by Replicant build dependency documentation was that I needed the Debian `xmllint` package to avoid a build failure and the Debian `xsltproc` package to avoid a error message being printed in the beginning of every build.  Soon I had my own fresh images and installed them and NFC was working again, after installing the non-free `libpn544_fw.so` file.
During this, I noticed that there are multiple `libpn544_fw.so` files floating around.  I have the following files:
```
version string source
libpn544_fw_C3_1_26_SP.so internet
libpn544_fw_C3_1_34_SP.so stock ROM on S3 bought in Sweden during 2013 and 2014 (two phones)
libpn544_fw_C3_1_39_SP.so internet

(For reference the md5sum's of these files are 682e50666effa919d557688c276edc48, b9364ba59de1947d4588f588229bae20 and 18b4e634d357849edbe139b04c939593 respectively.)

If you do not have any of these files available as /vendor/firmware/libpn544_fw.so you will get the following error message:

```I/NfcService( 2488): Enabling NFC
D/NFCJNI  ( 2488): Start Initialization
E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
E/NFCJNI  ( 2488): phLibNfc_Mgt_Initialize() returned 0x00ff[NFCSTATUS_FAILED]
E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFCJNI  ( 2488): Firmware update FAILED
E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFCJNI  ( 2488): Firmware update FAILED
E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFCJNI  ( 2488): Firmware update FAILED
E/NFCJNI  ( 2488): Unable to update firmware, giving up
D/NFCJNI  ( 2488): phLibNfc_Mgt_UnConfigureDriver() returned 0x0000[NFCSTATUS_SUCCESS]
D/NFCJNI  ( 2488): Terminating client thread...
W/NfcService( 2488): Error enabling NFC
```

Using the first (26) file or the last (39) file does not appear to be working on my phone, I get the following error messages. Note that the line starting with 'NFC capabilities' has 'Rev = 34' in it, possibly indicating that I need the version 34 file.

```I/NfcService( 5735): Enabling NFC
D/NFCJNI  ( 5735): Start Initialization
D/NFCJNI  ( 5735): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 8
D/NFCJNI  ( 5735): Download new Firmware
W/NFCJNI  ( 5735): Firmware update FAILED
D/NFCJNI  ( 5735): Download new Firmware
W/NFCJNI  ( 5735): Firmware update FAILED
D/NFCJNI  ( 5735): Download new Firmware
W/NFCJNI  ( 5735): Firmware update FAILED
E/NFCJNI  ( 5735): Unable to update firmware, giving up
D/NFCJNI  ( 5735): phLibNfc_Mgt_UnConfigureDriver() returned 0x0000[NFCSTATUS_SUCCESS]
D/NFCJNI  ( 5735): Terminating client thread...
W/NfcService( 5735): Error enabling NFC
```

Loading the 34 works fine.

```I/NfcService( 2501): Enabling NFC
D/NFCJNI  ( 2501): Start Initialization
D/NFCJNI  ( 2501): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0
D/NFCJNI  ( 2501): phLibNfc_SE_GetSecureElementList()
D/NFCJNI  ( 2501):
D/NFCJNI  ( 2501): > Number of Secure Element(s) : 1
D/NFCJNI  ( 2501): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI  ( 2501): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI  ( 2501): NFC Initialized
D/NdefPushServer( 2501): start, thread = null
D/NdefPushServer( 2501): starting new server thread
D/NdefPushServer( 2501): about create LLCP service socket
D/NdefPushServer( 2501): created LLCP service socket
D/NdefPushServer( 2501): about to accept
D/NfcService( 2501): NFC-EE OFF
D/NfcService( 2501): NFC-C ON
```

What is interesting is, that my other S3 running CyanogenMod does not have the libpn544_fw.so file but still NFC works. The messages are:

```I/NfcService( 2619): Enabling NFC
D/NFCJNI  ( 2619): Start Initialization
E/NFC-HCI ( 2619): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFC     ( 2619): Firmware image not available: this device might be running old NFC firmware!
D/NFCJNI  ( 2619): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0
D/NFCJNI  ( 2619): phLibNfc_SE_GetSecureElementList()
D/NFCJNI  ( 2619):
D/NFCJNI  ( 2619): > Number of Secure Element(s) : 1
D/NFCJNI  ( 2619): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI  ( 2619): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI  ( 2619): NFC Initialized
D/NdefPushServer( 2619): start, thread = null
D/NdefPushServer( 2619): starting new server thread
D/NdefPushServer( 2619): about create LLCP service socket
D/NdefPushServer( 2619): created LLCP service socket
D/NdefPushServer( 2619): about to accept
D/NfcService( 2619): NFC-EE OFF
D/NfcService( 2619): NFC-C ON
```

Diffing the two NFC-relevant repositories between Replicant (external_libnfc-nxp and packages_apps_nfc) and CyanogenMod (android_external_libnfc-nxp and android_packages_apps_Nfc) I found a commit in Replicant that changes a soft-fail on missing firmware to a hard-fail. I manually reverted that patch in my build tree, and rebuilt and booted a new image. Enabling NFC now prints this on my Replicant phone:

```I/NfcService( 2508): Enabling NFC
D/NFCJNI  ( 2508): Start Initialization
E/NFC-HCI ( 2508): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFC     ( 2508): Firmware image not available: this device might be running old NFC firmware!
D/NFCJNI  ( 2508): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0
D/NFCJNI  ( 2508): phLibNfc_SE_GetSecureElementList()
D/NFCJNI  ( 2508):
D/NFCJNI  ( 2508): > Number of Secure Element(s) : 1
D/NFCJNI  ( 2508): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI  ( 2508): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI  ( 2508): NFC Initialized
D/NdefPushServer( 2508): start, thread = null
D/NdefPushServer( 2508): starting new server thread
D/NdefPushServer( 2508): about create LLCP service socket
D/NdefPushServer( 2508): created LLCP service socket
D/NdefPushServer( 2508): about to accept
D/NfcService( 2508): NFC-EE OFF
D/NfcService( 2508): NFC-C ON
```

And NFC works! One less non-free blob on my phone.

I have double-checked that power-cycling the phone (even removing battery for a while) does not affect anything, so it seems the NFC chip has firmware loaded from the factory.

Question remains why that commit was added. Is it necessary on some other phone? I have no idea, other than if the patch is reverted, S3 owners will have NFC working with Replicant without non-free software added. Alternatively, make the patch apply only on the platform where it was needed, or even to all non-S3 builds.

Syndicated 2014-08-05 12:20:18 from Simon Josefsson's blog

Offline GnuPG Master Key and Subkeys on YubiKey NEO Smartcard

I have moved to a new OpenPGP key. There are many tutorials and blog posts on GnuPG key generation around, but none of them matched exactly the setup I wanted to have. So I wrote down the steps I took, to remember them if I need to in the future. Briefly my requirements were as follows:

• The new master GnuPG key is on an USB stick.
• The USB stick is only ever used on an offline computer.
• There are subkeys stored on a YubiKey NEO smartcard for daily use.
• I want to generate the subkeys using GnuPG so I have a backup.
• Some non-default hash/cipher preferences encoded into the public key.

After writing down the notes below, I posted about how to create a small JPEG image to embed in my OpenPGP key. I was planning to go live with the first key I generated, however as was gently pointed out to me, the JPEG image I generated was not optimal (too low quality and not sufficiently compressed). I have decided to retake the photo so I have a color image as a basis for size optimization. I don’t want to postpone using the new key though, so I stepped through all of these steps again (except adding the photo) to get a new key. This is why the notes below are for a key 1C5C4717 that is now revoked. My new real key is 54265E8C. I will add the photo to my 54265E8C key once I have a JPEG file that I’m happy with.

Offline machine

The offline machine setup I use is a Live CD on a machine that is physically well protected. I’m using the Debian Live CD version 7.5.0 GNOME Desktop. The password for the auto-logged in user is “live” which you need if the screen-saver kicks in. Configure the keyboard layout if you need to. Insert an USB memory stick. I’m using a VFAT filesystem to keep things simple; and for this writeup it happened to be mounted as `/media/FA21-BEC7` so you will have to replace that path with something that points to your USB stick. Open a terminal since the rest of this writeup will be done from a terminal window.

GnuPG configuration

Set your GnuPG home directory to point at the USB memory device. You will need to do this in every terminal windows you open that you want to use GnuPG in.

```user@debian:~\$ export GNUPGHOME=/media/FA21-BEC7/gnupghome
user@debian:~\$ mkdir \$GNUPGHOME
user@debian:~\$
```

The GnuPG defaults (as of version 1.4.16) to rank SHA1 higher than SHA384, SHA512, and SHA224 in the default hash preference list. To be precise, the default hash preference order is SHA256, SHA1, SHA384, SHA512, SHA224. I consider SHA1 broken so I don’t advertise it all, although I believe that will not prevent some implementations of using SHA1 anyway since it is the mandatory to implement hash algorithm. Regarding symmetric ciphers, the default order is AES256, AES192, AES128, CAST5, 3DES. I don’t like ciphers with 64-bit block lengths, so I don’t advertise them but similarily, I believe this will not prevent some implementations of using CAST5 or 3DES anyway. I also advertise support for Twofish and Camellia in case someone wants to use them, they are 128-bit block length and relatively modern ciphers after all. The “default-preference-list” keyword is used to override the default settings, which will be recorded into any newly generated keys.

GnuPG self-sign keys with SHA1 by default, and I prefer to use a member of the SHA2 family, hence the “cert-digest-algo” keyword. Further down below we will use the GnuPG Agent to talk to the smartcard, so configure GnuPG to use it with the “use-agent” keyword. GnuPG prints ugly warning messages about locking (`gpg: DBG: locking for `/media/FA21-BEC7/gnupghome/secring.gpg.lock' done via O_EXCL`), presumably because of the VFAT filesystem, so I use “lock-never” to silence that.

```user@debian:~\$ cat > \$GNUPGHOME/gpg.conf
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAMELLIA256 CAMELLIA192 CAMELLIA128 TWOFISH
cert-digest-algo SHA512
use-agent
lock-never
user@debian:~\$
```

Generate master key

Below I will use a 3744 bit RSA key, where the key size is selected based on the assumption that people will focus efforts to crack RSA keys on the usual power-of-two key sizes. I have chosen to not generate an encryption key, since I will use subkeys on a smartcard. With my old B565716F key I noticed that sometimes people will encrypt to my main encryption key even though I have encryption subkeys. Presumably this happens due to implementation flaws or user configuration mistakes. It could happen “intentionally” if someone had a public key from me with an expired subkeys but not expired main keys. This could be a reason to use the same expiration day for all your keys. Still, I chose to not generate an encryption key at all at this point. For additional protection, I’m using a passphrase on the key.

```user@debian:~\$ gpg --gen-key
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: keyring `/media/FA21-BEC7/gnupghome/secring.gpg' created
gpg: keyring `/media/FA21-BEC7/gnupghome/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 3744
Requested keysize is 3744 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 100
Key expires at Fri 26 Sep 2014 10:50:22 PM UTC
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) "

Real name: Simon Josefsson
Email address: simon@josefsson.org
Comment:
You selected this USER-ID:
"Simon Josefsson "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
...
gpg: /media/FA21-BEC7/gnupghome/trustdb.gpg: trustdb created
gpg: key 1C5C4717 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2014-09-26
pub   3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
Key fingerprint = EF0A 1996 7B3B 4BAD 9D5C  A97F 1A44 08DD 1C5C 4717
uid                  Simon Josefsson

Note that this key cannot be used for encryption.  You may want to use
the command "--edit-key" to generate a subkey for this purpose.
user@debian:~\$
```

Add photo

I’m in the process of creating a better JPEG photo, so I skipped this step for my new key. However the notes here are correct anyway.

```user@debian:~\$ gpg --edit-key 1C5C4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
[ultimate] (1). Simon Josefsson

gpg> addphoto

Pick an image to use for your photo ID.  The image must be a JPEG file.
Remember that the image is stored within your public key.  If you use a
very large picture, your key will become very large as well!
Keeping the image close to 240x288 is a good size to use.

Enter JPEG filename for photo ID: /media/FA21-BEC7/simon-gpg.jpg
Is this photo correct (y/N/q)? y

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
[ultimate] (1). Simon Josefsson
[ unknown] (2)  [jpeg image of size 6048]

gpg> save
user@debian:~\$
```

Add another identity

Most people have multiple email addresses, and this needs to be reflected in the GnuPG key. Use the `primary` command to specify your main User ID.

```user@debian:~\$ gpg --edit-key 1C5C4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
[ultimate] (1). Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]

gpg> adduid
Real name: Simon Josefsson
Email address: simon@yubico.com
Comment:
You selected this USER-ID:
"Simon Josefsson "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
[ultimate] (1)  Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]
[ unknown] (3). Simon Josefsson

gpg> uid 1

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
[ultimate] (1)* Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]
[ unknown] (3). Simon Josefsson

gpg> primary

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
[ultimate] (1)* Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]
[ unknown] (3)  Simon Josefsson

gpg> save
user@debian:~\$
```

Create a revocation certificate

It is good practice to generate a revocation certificate in case you lose your key. Store this in a safe place, possibly printed out on paper.

```user@debian:~\$ gpg --output \$GNUPGHOME/../revocation-certificate.txt --gen-revoke 1C5C4717

sec  3744R/1C5C4717 2014-06-18 Simon Josefsson

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> Created during key creation, emergency use only.
>
Reason for revocation: Key has been compromised
Created during key creation, emergency use only.
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18

ASCII armored output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!
user@debian:~\$
```

Make a backup of the master key

To have an easy way to move back and forward in time in GnuPG, I both export the key to a stable data format and keep a backup of the actual GnuPG home directory.

```user@debian:~\$ gpg -a --export-secret-keys 1C5C4717 > \$GNUPGHOME/../masterkey.txt
user@debian:~\$ cp -a \$GNUPGHOME \$GNUPGHOME-backup-masterkey
user@debian:~\$
```

Create subkeys

Now I will generate three keys that will go onto the smartcard. I have chosen to generate these using GnuPG and then move the keys onto the smartcards, instead of generating the keys directly on the card. The difference is that with this approach, I get a backup of the keys and can import them to another key in the future if I need to.

Each key has its own purpose: Signature, Encryption, and Authentication. Smartcards typically have limitation on key sizes, so I select 2048 as a widely supported size. Expert mode is required to generate authentication subkeys.

```user@debian:~\$ gpg --expert --edit-key 1C5C4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
[ultimate] (1). Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson

gpg> addkey
Key is protected.

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18

Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 100
Key expires at Fri 26 Sep 2014 11:03:16 PM UTC
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..+++++
....+++++

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S
[ultimate] (1). Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson

gpg> addkey
Key is protected.

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18

Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
Your selection? 6
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 100
Key expires at Fri 26 Sep 2014 11:03:31 PM UTC
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
......+++++

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 7 more bytes)
.+++++

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E
[ultimate] (1). Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson

gpg> addkey
Key is protected.

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18

Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
Your selection? 8

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt

(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished

Your selection? s

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Encrypt

(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished

Your selection? e

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions:

(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished

Your selection? a

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Authenticate

(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished

Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 100
Key expires at Fri 26 Sep 2014 11:03:59 PM UTC
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 56 more bytes)
+++++

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson

gpg> save
user@debian:~\$
```

Export subkeys for backup

This is a good time to save a restore point for your key. Note in the output of `--list-secret-keys` the keywords sec and ssb which means the main key and the subkeys are available. If the secret keyring contained only stubs, it would be sec> and sec#.

```user@debian:~\$ gpg --list-keys
/media/FA21-BEC7/gnupghome/pubring.gpg
--------------------------------------
pub   3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
uid                  Simon Josefsson
uid                  [jpeg image of size 6048]
uid                  Simon Josefsson
sub   2048R/72D5245B 2014-06-18 [expires: 2014-09-26]
sub   2048R/A11F46D2 2014-06-18 [expires: 2014-09-26]
sub   2048R/D6987A02 2014-06-18 [expires: 2014-09-26]

user@debian:~\$ gpg --list-secret-keys
/media/FA21-BEC7/gnupghome/secring.gpg
--------------------------------------
sec   3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
uid                  Simon Josefsson
uid                  [jpeg image of size 6048]
uid                  Simon Josefsson
ssb   2048R/72D5245B 2014-06-18
ssb   2048R/A11F46D2 2014-06-18
ssb   2048R/D6987A02 2014-06-18

user@debian:~\$ gpg -a --export-secret-keys 1C5C4717 > \$GNUPGHOME/../mastersubkeys.txt
user@debian:~\$ gpg -a --export-secret-subkeys 1C5C4717 > \$GNUPGHOME/../subkeys.txt
user@debian:~\$ cp -a \$GNUPGHOME \$GNUPGHOME-backup-mastersubkeys
user@debian:~\$
```

Configure machine for smartcards

The YubiKey NEO requires that RSA keys are imported with some additional parameters, used for CRT speedups. This was fixed in GnuPG 2.0.22. Unfortunately, it is not fixed in GnuPG 1.x. However, GnuPG 1.x can use gpg-agent and scdaemon from GnuPG to communicate with the smartcard. So let’s work around the limitation in GnuPG 1.x by installing parts from GnuPG 2.x and use those.

You will need to install the following packages: gnupg-agent, libpth20, pinentry-curses, libccid, pcscd, scdaemon, libksba8. Make sure that scdaemon is version 2.0.22 or later (get it from backports). I downloaded these packages and put them on the USB stick.

Unfortunately, libccid in Debian is a bit outdated, and does not contain the USB device vendor/product ID in /etc/libccid_Info.plist. You will need to manually add this, and restart pcscd.

user@debian:~\$ sudo gedit /etc/libccid_Info.plist
user@debian:~\$ sudo service pcscd restart

Start gnupg-agent and setup the environment variable for this session:

```user@debian:~\$ gpg-agent --daemon
gpg-agent[22556]: directory `/media/FA21-BEC7/gnupghome/private-keys-v1.d' created
GPG_AGENT_INFO=/tmp/gpg-wGji5C/S.gpg-agent:22557:1; export GPG_AGENT_INFO;
gpg-agent[22557]: gpg-agent (GnuPG) 2.0.22 started
user@debian:~\$ GPG_AGENT_INFO=/tmp/gpg-wGji5C/S.gpg-agent:22557:1; export GPG_AGENT_INFO;
user@debian:~\$
```

Prepare YubiKey NEO

Make sure you have a recent firmware version, 3.1.8 or later; use `lsusb -v` to find out.

Make sure the device is in OTP/CCID or CCID mode, use `ykpersonalize -m` from the YubiKey Personalization project to switch.

Make sure you have the OpenPGP applet loaded properly, otherwise see the YubiKey NEO OpenPGP applet project on installing it. You may want to set a proper Application ID, see herlo’s ssh-gpg-smartcard-config github repository for some hints.

Configure OpenPGP applet

This also changes the PIN and Admin codes.

```user@debian:~\$ gpg --card-edit

Application ID ...: D2760001240102000060000000420000
Version ..........: 2.0
Manufacturer .....: unknown
Serial number ....: 00000042
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

gpg/card> admin
Admin commands are allowed

gpg/card> passwd
gpg: OpenPGP card no. D2760001240102000060000000420000 detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 3
PIN changed.

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 1
PIN changed.

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? q

gpg/card> name
Cardholder's surname: Josefsson
Cardholder's given name: Simon

gpg/card> lang
Language preferences: sv

gpg/card> url
URL to retrieve public key: https://josefsson.org/1c5c4717.txt

gpg/card> sex
Sex ((M)ale, (F)emale or space): m

gpg/card> login
Login data (account name): jas

gpg/card>

Application ID ...: D2760001240102000060000000420000
Version ..........: 2.0
Manufacturer .....: unknown
Serial number ....: 00000042
Name of cardholder: Simon Josefsson
Language prefs ...: sv
Sex ..............: male
URL of public key : https://josefsson.org/1c5c4717.txt
Login data .......: jas
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

gpg/card> quit
user@debian:~\$
```

Move subkeys to YubiKey NEO

Moving subkeys to a NEO is a destructive operation, so make sure you took backups of the subkeys as above. After this step, your GnuPG keyring will contain stubs for the subkeys.

```user@debian:~\$ gpg --edit-key 1C5C4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: ultimate
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A
[ultimate] (1). Simon Josefsson
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson

gpg> toggle

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never
ssb  2048R/D6987A02  created: 2014-06-18  expires: never
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> key 1

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb* 2048R/72D5245B  created: 2014-06-18  expires: never
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never
ssb  2048R/D6987A02  created: 2014-06-18  expires: never
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> keytocard
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]

Please select where to store the key:
(1) Signature key
(3) Authentication key
Your selection? 1

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
2048-bit RSA key, ID 72D5245B, created 2014-06-18

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb* 2048R/72D5245B  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never
ssb  2048R/D6987A02  created: 2014-06-18  expires: never
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> key 1

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never
ssb  2048R/D6987A02  created: 2014-06-18  expires: never
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> key 2

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb* 2048R/A11F46D2  created: 2014-06-18  expires: never
ssb  2048R/D6987A02  created: 2014-06-18  expires: never
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> keytocard
Signature key ....: EF34 D1F7 95C0 3392 E52A  54FE DFF1 6372 72D5 245B
Encryption key....: [none]
Authentication key: [none]

Please select where to store the key:
(2) Encryption key
Your selection? 2

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
2048-bit RSA key, ID A11F46D2, created 2014-06-18

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb* 2048R/A11F46D2  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb  2048R/D6987A02  created: 2014-06-18  expires: never
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> key 2

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb  2048R/D6987A02  created: 2014-06-18  expires: never
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> key 3

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb* 2048R/D6987A02  created: 2014-06-18  expires: never
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> keytocard
Signature key ....: EF34 D1F7 95C0 3392 E52A  54FE DFF1 6372 72D5 245B
Encryption key....: E24D 5135 C2FC 905C 8995  ACD8 EC96 9E77 A11F 46D2
Authentication key: [none]

Please select where to store the key:
(3) Authentication key
Your selection? 3

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
2048-bit RSA key, ID D6987A02, created 2014-06-18

sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never
card-no: 0060 00000042
ssb* 2048R/D6987A02  created: 2014-06-18  expires: never
card-no: 0060 00000042
(1)  Simon Josefsson
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson

gpg> save
user@debian:~\$
```

Take another backup

Can you tell yet that I like having backup options? Note that the subkeys are now marked `ssb>` indicating they are stubs for a smartcard key.

```user@debian:~\$ gpg --list-secret-keys
/media/FA21-BEC7/gnupghome/secring.gpg
--------------------------------------
sec   3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
uid                  Simon Josefsson
uid                  [jpeg image of size 6048]
uid                  Simon Josefsson
ssb>  2048R/72D5245B 2014-06-18
ssb>  2048R/A11F46D2 2014-06-18
ssb>  2048R/D6987A02 2014-06-18

user@debian:~\$ gpg -a --export-secret-keys 1C5C4717 > \$GNUPGHOME/../masterstubs.txt
user@debian:~\$ gpg -a --export-secret-subkeys 1C5C4717 > \$GNUPGHOME/../subkeysstubs.txt
user@debian:~\$ gpg -a --export 1C5C4717 > \$GNUPGHOME/../publickey.txt
user@debian:~\$ cp -a \$GNUPGHOME \$GNUPGHOME-backup-masterstubs
```

Transfer to daily machine

Copy publickey.txt to your day-to-day laptop and import it.

```jas@latte:~\$ gpg --import " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
jas@latte:~\$
```

Insert the YubiKey NEO and generate secret key stubs:

```jas@latte:~\$ gpg --card-status
Application ID ...: D2760001240102000060000000420000
Version ..........: 2.0
Manufacturer .....: unknown
Serial number ....: 00000042
Name of cardholder: Simon Josefsson
Language prefs ...: sv
Sex ..............: male
URL of public key : https://josefsson.org/1c5c4717.txt
Login data .......: jas
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 0 0 0
PIN retry counter : 0 0 0
Signature counter : 0
Signature key ....: EF34 D1F7 95C0 3392 E52A  54FE DFF1 6372 72D5 245B
created ....: 2014-06-18 23:03:16
Encryption key....: E24D 5135 C2FC 905C 8995  ACD8 EC96 9E77 A11F 46D2
created ....: 2014-06-18 23:03:31
Authentication key: 2768 2EF9 415C 19FC F0CC  9CA5 DA81 BA39 D698 7A02
created ....: 2014-06-18 23:03:59
General key info..: pub  2048R/72D5245B 2014-06-18 Simon Josefsson
sec#  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb>  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26
card-no: 0060 00000042
ssb>  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26
card-no: 0060 00000042
ssb>  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26
card-no: 0060 00000042
jas@latte:~\$
```

Now you should have a offline master key with subkey stubs. Note that the master key is not available (`sec#`) and the subkeys are stubs for smartcard keys (`ssb>`).

```jas@latte:~\$ gpg --list-secret-keys 1c5c4717
sec#  3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
uid                  Simon Josefsson
uid                  [jpeg image of size 6048]
uid                  Simon Josefsson
ssb>  2048R/72D5245B 2014-06-18 [expires: 2014-09-26]
ssb>  2048R/A11F46D2 2014-06-18 [expires: 2014-09-26]
ssb>  2048R/D6987A02 2014-06-18 [expires: 2014-09-26]
jas@latte:~\$
```

Mark the key as ultimately trusted.

```jas@latte:~\$ gpg --edit-key 1c5c4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: unknown       validity: unknown
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A
[ unknown] (1). Simon Josefsson
[ unknown] (2)  [jpeg image of size 6048]
[ unknown] (3)  Simon Josefsson

gpg> trust
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: unknown       validity: unknown
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A
[ unknown] (1). Simon Josefsson
[ unknown] (2)  [jpeg image of size 6048]
[ unknown] (3)  Simon Josefsson

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y

pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC
trust: ultimate      validity: unknown
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A
[ unknown] (1). Simon Josefsson
[ unknown] (2)  [jpeg image of size 6048]
[ unknown] (3)  Simon Josefsson
Please note that the shown key validity is not necessarily correct
unless you restart the program.

gpg> quit
jas@latte:~\$
```

Signing keys

This needs to be done using your master key, since it is your certification key that will be used. So boot the Live CD and make the usual GnuPG configurations. Below I’m signing my own old key (0xB565716F) so the output may look a bit confusing with me signing my own key, but there is really two different keys involved here. The same process apply if you want to sign someone else’s key too.

Before signing the key, you need to put the public key on a USB stick and move it to the “secure” machine. On your laptop:

```jas@latte:~\$ gpg -a --export b565716f > /media/KINGSTON/b565716f.txt
jas@latte:~\$
```

On the disconnected machine:

```user@debian:~\$ gpg --import " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2014-09-26
user@debian:~\$ gpg --sign-key b565716f

pub  1280R/B565716F  created: 2002-05-05  expires: 2014-11-10  usage: SC
trust: unknown       validity: unknown
sub  2048R/105E722E  created: 2012-03-13  expires: 2014-11-10  usage: S
sub  2048R/728AB82C  created: 2012-03-13  expires: 2014-11-10  usage: E
sub  2048R/9394F626  created: 2012-03-13  expires: 2014-11-10  usage: A
sub  1280R/4D5D40AE  created: 2002-05-05  expires: 2014-11-10  usage: E
sub  1024R/09CC4670  created: 2006-03-18  expired: 2011-05-23  usage: A
sub  1024R/AABB1F7B  created: 2006-03-18  expired: 2011-05-23  usage: S
sub  1024R/A14C401A  created: 2006-03-18  expired: 2011-05-23  usage: E
[ unknown] (1). Simon Josefsson
[ unknown] (2)  Simon Josefsson
[ revoked] (3)  Simon Josefsson

Really sign all user IDs? (y/N) y
User ID "Simon Josefsson " is revoked.  Unable to sign.

pub  1280R/B565716F  created: 2002-05-05  expires: 2014-11-10  usage: SC
trust: unknown       validity: unknown
Primary key fingerprint: 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F

Simon Josefsson
Simon Josefsson

This key is due to expire on 2014-11-10.
Are you sure that you want to sign this key with your
key "Simon Josefsson " (1C5C4717)

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18

user@debian:~\$
```

Then export the newly signed key back to your laptop for further distribution.

```user@debian:~\$ gpg -a --export b565716f > /media/KINGSTON/signed-b565716f.txt
user@debian:~\$
```

On your laptop, either email it encrypted to the other person, or upload it to keyservers directly depending on your preference. By emailing it encrypted to the other person, they need to prove posession of the key before receiving your signature. In my case, I’m the other person, so I just import the signed key and then send the key:

```jas@latte:~\$ gpg --import
Key transition
Since I'm migrating from an key to a new, I sign my new key using my old key, and publish that signature on keyservers.  This allows people to trust my new key more easily.
To let the world know about your key transition, I created a key transition statement.  The transition statement should be signed by both keys.  I created a new temporary GnuPG home directory and imported both master keys, and clearsigned the file.  Note that I used "54265e8c!" to make GnuPG use the master key for signing rather than a subkey, which it would normally do.
user@debian:~\$ export GNUPGHOME=/tmp/kts
user@debian:~\$ mkdir \$GNUPGHOME
user@debian:~\$ gpg --import b565716f.txt
gpg: WARNING: unsafe permissions on homedir `/tmp/kts'
gpg: keyring `/tmp/kts/secring.gpg' created
gpg: keyring `/tmp/kts/pubring.gpg' created
gpg: key B565716F: secret key imported
gpg: /tmp/kts/trustdb.gpg: trustdb created
gpg: key B565716F: public key "Simon Josefsson " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
user@debian:~\$ gpg --import /media/FA21-AE97/secret-master-subkeys.txt
gpg: WARNING: unsafe permissions on homedir `/tmp/kts'
gpg: key 54265E8C: secret key imported
gpg: key 54265E8C: public key "Simon Josefsson " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
user@debian:~\$ cat key-transition-2014-06-22-unsigned.txt | gpg --clearsign --personal-digest-preferences "SHA512" --local-user b565716f --local-user 54265e8c! > key-transition-2014-06-22.txt
gpg: WARNING: unsafe permissions on homedir `/tmp/kts'

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 54265E8C, created 2014-06-22

You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
1280-bit RSA key, ID B565716F, created 2002-05-05

user@debian:~\$

My statement is available as https://josefsson.org/key-transition-2014-06-22.txt if you want to download the signed text file directly.  Feel free to base your own document on it, as I based mine on earlier examples.
```

Syndicated 2014-06-23 11:18:38 from Simon Josefsson's blog

OpenPGP Key Transition Statement

I have created a new OpenPGP key 54265e8c and will be transitioning away from my old key. If you have signed my old key, I would appreciate signatures on my new key as well. I have created a transition statement that can be downloaded from https://josefsson.org/key-transition-2014-06-22.txt.

Below is the signed statement.

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

OpenPGP Key Transition Statement for Simon Josefsson

I have created a new OpenPGP key and will be transitioning away from
my old key.  The old key has not been compromised and will continue to
be valid for some time, but I prefer all future correspondence to be
encrypted to the new key, and will be making signatures with the new
key going forward.

I would like this new key to be re-integrated into the web of trust.
This message is signed by both keys to certify the transition.  My new
and old keys are signed by each other.  If you have signed my old key,
I would appreciate signatures on my new key as well, provided that
your signing policy permits that without re-authenticating me.

The old key, which I am transitioning away from, is:

pub   1280R/B565716F 2002-05-05
Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F

The new key, to which I am transitioning, is:

pub   3744R/54265E8C 2014-06-22
Key fingerprint = 9AA9 BDB1 1BB1 B99A 2128  5A33 0664 A769 5426 5E8C

The entire key may be downloaded from: https://josefsson.org/54265e8c.txt

To fetch the full new key from a public key server using GnuPG, run:

gpg --keyserver keys.gnupg.net --recv-key 54265e8c

If you already know my old key, you can now verify that the new key is
signed by the old one:

gpg --check-sigs 54265e8c

If you are satisfied that you've got the right key, and the User IDs
match what you expect, I would appreciate it if you would sign my key:

gpg --sign-key 54265e8c

You can upload your signatures to a public keyserver directly:

gpg --keyserver keys.gnupg.net --send-key 54265e8c

Or email simon@josefsson.org (possibly encrypted) the output from:

gpg --armor --export 54265e8c

If you'd like any further verification or have any questions about the
transition please contact me directly.

To verify the integrity of this statement:

wget -q -O- https://josefsson.org/key-transition-2014-06-22.txt|gpg --verify

/Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iLwEAQEKAAYFAlOnV+AACgkQ7aIelLVlcW89XgUAljJgYfReyR9/bU+Om6UHUttt
CAOgSRqdcQSQ2hT69vzuhb/bc8CslIQcBtGqTgxDFsxEFhbm5zKn+tSzy5MHNHqt
MsqHcZjlYuYVhMXDhka+cfyhtd9zIxjVE5vk8v+GqEGoh8DGYq0vPy3VfvcSz5Z3
MSUpSj8gN00jlU1z4nad3maEq0ApvsLr8EsLZmtxF5TNFvzJ8mmwY+gHBGHjVYkB
8AQBAQoABgUCU6dX4AAKCRAGZKdpVCZejD1eDp46XGL2puMp0le2OF75WIUW8xqf
TMiZeB99ruk3P/jvuLnGPP2J5o7SIKE50FkMEss0yvxi6jBlHk+cJeKWGXVjBpxU
0QHq063NU+kjbMYwDfi5ZxXqaKeYODJm8Xmfh3d7lRaWF5rUOosR8nC/OROSrhg4
TjlAbvbxpQsls/JPbbporK2gbAtMlzJPD8zC8z/dT+t0qjlce8fADugblVW3bACC
Kl53X4XpojzNd/U19tSXkIBdNY/GVJqci+iruiJ1WGARF9ocnIXVuNXsfyt7UGq4
UiM/AeDVzI76v1QnE8WpsmSXzi2zXe3VahUPhOU2nPDoL53ggiVsTY3TwilvQLfX
Av/74PIaEtCi1g23YeojQlpdYzcWfnE+tUyTSNwPIBzyzHvFAHNg1Pg0KKUALsD9
P7EjrMuz63z2276EBKX8++9GnQQNCNfdHSuX4WGrBx2YgmOOqRdllMKz6pVMZdJO
V+gXbCMx0D5G7v50oB58Mb5NOgIoOnh3IQhJ7LkLwmcdG39yCdpU+92XbAW73elV
kmM8i0wsj5kDUU2ys32Gj2HnsVpbnh3Fvm9fjFJRbbQL/FxNAjzNcHe4cF3g8hTb
YVJJlzhmHGvd7HvXysJJaa0=
=ZaqY
-----END PGP SIGNATURE-----
```

Syndicated 2014-06-22 22:29:32 from Simon Josefsson's blog

Creating a small JPEG photo for your OpenPGP key

I’m in the process of moving to a new OpenPGP key, and I want to include a small JPEG image of myself in it. The OpenPGP specification describes, in section 5.12.1 of RFC 4880, how an OpenPGP packet can contain an JPEG image. Unfortunately the document does not require or suggest any properties of images, nor does it warn about excessively large images. The GnuPG manual helpfully asserts that “Note that a very large JPEG will make for a very large key.”.

Researching this further, it seems that proprietary PGP program suggests 120×144 as the maximum size, although I haven’t found an authoritative source of that information. Looking at the GnuPG code, you can see that it suggests around 240×288 in a string saying “Keeping the image close to 240×288 is a good size to use”. Further, there is a warning displayed if the image is above 6144 bytes saying that “This JPEG is really large”.

I think the 6kb warning point is on the low side today, however without any more researched recommendation of image size, I’m inclined to go for a 6kb 240×288 image. Achieving this was not trivial, I ended up using GIMP to crop an image, resize it to 240×288, and then export it to JPEG. Chosing the relevant parameters during export is the tricky part. First, make sure to select ‘Show preview in image window’ so that you get a file size estimate and a preview of how the photo will look. I found the following settings useful for reducing size:

• Disable “Save EXIF data”
• Disable “Save thumbnail”
• Disable “Save XMP data”
• Change “Subsampling” from the default “4:4:4 (best quality)” to “4:2:0 (chroma quartered)”.
• Try enabling only one of “Optimize” and “Progressive”. Sometimes I get best results disabling one and keeping the other enabled, and sometimes the other way around. I have not seen smaller size with both enabled, nor with both disabled.
• Smooth the picture a bit to reduce pixel effects and size.
• Change quality setting, I had to reduce it to around 25%.

See screenshot below of the settings windows.

Eventually, I managed to get a photo that I was reasonable happy with. It is 240×288 and is 6048 bytes large.

If anyone has further information, or opinions, on what image sizes makes sense for OpenPGP photos, let me know. Ideas on how to reduce size of JPEG images further without reducing quality as much would be welcome.

Syndicated 2014-06-19 11:55:24 from Simon Josefsson's blog

Replicant 4.2 on Samsung S3

Since November 2013 I have been using Replicant on my Samsung S3 as an alternative OS. The experience has been good for everyday use. The limits (due to non-free software components) compared to a “normal” S3 (running vendor ROM or CyanogenMod) is lack of GPS/wifi/bluetooth/NFC/frontcamera functionality — although it is easy to get some of that working again, including GPS, which is nice for my geocaching hobby. The Replicant software is stable for being an Android platform; better than my Nexus 7 (2nd generation) tablet which I got around the same time that runs an unmodified version of Android. The S3 has crashed around ten times in these four months. I’ve lost track of the number of N7 crashes, especially after the upgrade to Android 4.4. I use the N7 significantly less than the S3, reinforcing my impression that Replicant is a stable Android. I have not had any other problem that I couldn’t explain, and have rarely had to reboot the device.

The Replicant project recently released version 4.2 and while I don’t expect the release to resolve any problem for me, I decided it was time to upgrade and learn something new. This time I decided to use the pre-built ROM images rather to build my own because I had issues building replicant 4.2 on my Debian wheezy machine (C++ compilation errors which apparently does not happen if you use a newer compiler).

Before the installation, I wanted to have a full backup of the phone to avoid losing data. I use SMS Backup+ to keep a backup of my call log, SMS and MMS on my own IMAP server. I use oandbackup to take a backup of all software and settings on the phone. I use DAVDroid for my contacts and calendar (using a Radicale server), and reluctantly still use aCal in order to access my Google Calendar (because Google does not implement RFC 5397 properly so it doesn’t work with DAVDroid). Alas all that software is not sufficient for backup purposes, for example photos are still not copied elsewhere. In order to have a complete backup of the phone, I connect the phone using a USB cable and enable USB tethering on the phone. The network is automatically set up on my Debian machine, I did not have to do anything. Then I invoke the following commands to take a backup using rsync:

```adb shell dropbear -F -E & sudo rsync -av --delete --exclude /dev --exclude /acct --exclude /sys --exclude /proc -e ssh root@192.168.42.129:/ /root/s3-bup/```

Now feeling safe that I would not lose any data, I removed the SIM card from my phone (to avoid having calls, SMS or cell data interrupt during the installation) and followed the Replicant Samsung S3 installation documentation. Installation was straightforward. I booted up the newly installed ROM and familiarized myself with it. My first reaction was that the graphics felt a bit slower compared to Replicant 4.0, but it is hard to tell for certain.

I connected to the network using USB tethering and took a quick rsync-backup of the freshly installed phone, to have a starting point for future backups. Since my IMAP and CardDav/CalDav servers use certificates signed by CACert I first had to install the CACert trust anchors, to get SMS Backup+ and DAVDroid to connect. For some reason it was not sufficient to add only the root CACert certificate, so I had to add the Class 3 sub-ca cert as well. To load the certs, I invoke the following commands, selecting ‘Install from SD Card’ when the menu is invoked (twice).

```adb push root.crt /sdcard/ adb shell am start -n "com.android.settings/.Settings\"\\$\"SecuritySettingsActivity" adb push class3.crt /sdcard/ adb shell am start -n "com.android.settings/.Settings\"\\$\"SecuritySettingsActivity"```

I restore apps with oandbackup, and I select a set of important apps that I want restored with settings preserved, including aCal, K9, Xabber, c:geo, OsmAnd~, NewsBlur, Google Authenticator. I install SMS Backup+ from FDroid separately and configure it, SMS Backup+ doesn’t seem to want to restore anything if the app was restored with settings using oandbackup. I install and configure the DAVdroid account with the server URL, and watch it populate my address book and calendar with information.

After organizing the icons on the launcher screen, and changing the wallpaper, I’m up and running with Replicant 4.2. This upgrade effort took me around two days to complete, with around half of the time consumed by exploring different ways to do the rsync backup before I settled on dropbear and USB tethering. Compared to the last time, when I spent almost two weeks researching various options and preparing for the install, this felt like a swift process.

I spent some time researching how to get the various non-free components running. This is of course sub-optimal, and the Replicant project does not endorse non-free software. Alas there aren’t any devices out there that meets my requirements and use only free software. Personally, I feel using a free core OS like Replicant and then adding some non-free components back is a better approach than using CyanogenMod directly, or (horror) the stock ROM. Even better is of course to not add these components back, but you have to decide for yourselves which trade-offs you want to make. The Replicant wiki has a somewhat outdated page on Samsung S3 firmware. Below are my notes for each component, which applies to Replicant 4.2 0001. You need to first prepare your device a bit using these commands, and it is a good idea to reboot the device after installing the files.

```adb root adb shell mount -o rw,remount /system adb shell mkdir /system/vendor/firmware adb shell chmod 755 /system/vendor/firmware```

GPS: The required files are the same as for Replicant 4.0, and using the files from CyanogenMod 10.1.3 works fine. The following commands load them onto the device. Note that this will load code that will execute on your main CPU which is particularly bothersome. There seems to exist a number of different versions of these files, CyanogenMod have the same gpsd and gps.exynos4.so in version 10.1.3 and 10.2 but the libsecril-client.so differs between 10.1.3 and 10.2. All files differ from the files I got with my stock Samsung ROM on this device (MD5 checksums in my previous blog). I have not investigated how these versions differs or which of them should be recommended. I use the files from CyanogenMod 10.1.3 because it matches the Android version and because the files are easily available.

```adb push cm-10.1.3-i9300/system/bin/gpsd /system/bin/gpsd adb shell chmod 755 /system/bin/gpsd adb push cm-10.1.3-i9300/system/lib/hw/gps.exynos4.so /system/lib/hw/gps.exynos4.so adb push cm-10.1.3-i9300/system/lib/libsecril-client.so /system/lib/libsecril-client.so adb shell chmod 644 /system/lib/hw/gps.exynos4.so /system/lib/libsecril-client.so```

Bluetooth: Only one file has to be installed, apparently firmware loaded onto the Bluetooth chip. Cyanogenmod 10.1.3 and 10.2 contains identical files, which has a string in it “BCM4334B0 37.4MHz Class1.5 Samsung D2″. The file I got with my stock ROM has a string in it “BCM4334B0 37.4MHz Class1.5 Samsung M0″. I don’t know the difference, although I have seen that D2 sometimes refers to the US version of a Samsung device. My device is the international version, but it seems to work anyway.

```adb push cm-10.1.3-i9300/system/bin/bcm4334.hcd /system/vendor/firmware/bcm4334.hcd adb shell chmod 644 /system/vendor/firmware/bcm4334.hcd```

Front Camera: Two files has to be installed, apparently firmware loaded onto the Camera chip. CyanogenMod 10.1.3 and 10.2 contains identical files, which has a string in it “[E4412 520-2012/08/30 17:35:56]OABH30″. The file I got with my stock ROM has a string in it “[E4412 533-2012/10/06 14:38:46]OABJ06″. I don’t know the difference.

```adb push cm-10.1.3-i9300/system/vendor/firmware/fimc_is_fw.bin /system/vendor/firmware/fimc_is_fw.bin adb push cm-10.1.3-i9300/system/vendor/firmware/setfile.bin /system/vendor/firmware/setfile.bin adb shell chmod 644 /system/vendor/firmware/fimc_is_fw.bin /system/vendor/firmware/setfile.bin```

NFC: I’m happy that I got NFC to work, this was one of my main issues with Replicant 4.0 (see my earlier blog post). Only one file is needed, however CyanogenMod does not seem to distribute it so you have to get it from your stock ROM or elsewhere. The md5 of the file I have is b9364ba59de1947d4588f588229bae20 (and no I will not send it to you). I have tested it with the YubiKey NEO and the Yubico Authenticator app.

```adb push clockworkmod/blobs/ee6/7188ca465cf01dd355a92685a42361e113f886ef44e96d371fdaebf57acae /system/vendor/firmware/libpn544_fw.so adb shell chmod 644 /system/vendor/firmware/libpn544_fw.so```

Wifi: I haven’t gotten wifi to work, although I have not tried very hard. Loading the CyanogenMod firmwares makes my device find wireless networks, but when I try to authenticate (WPA-PSK2), I get failures. Possibly some other files has to be loaded as well.

Syndicated 2014-02-27 11:07:45 from Simon Josefsson's blog

Necrotizing Fasciitis

Dear World,

On the morning of the 24th December I felt a unusual pain in my left hand between the thumb and forefinger. The pain increased and I got high fever (at some point above 40 degrees Celsius or 104 degree Fahrenheit), and was hospitalized during the night between the 24th and 25th of December. On the afternoon of 26th of December I underwent surgery and was after that diagnosed with Necrotizing Fasciitis (the wikipedia article on NF gives a good summary), caused by the common streptococcus bacteria (again see wikipedia article on Streptococcus). A popular name for the disease is flesh-eating bacteria. Necrotizing Fasciitis is a rare and aggresive infection, deadly if left untreated, that can move through the body at speeds of a couple of centimeters per hour. Fortunately I was healthy at the time when this started, and with bi-weekly training sessions for the last 1.5 year I was physically at my strongest peak in my 38 year old life (weighting 78kg or 170lb, height 182cm or 6 inches). I started working out to improve back issues, improve strength, and prepare for getting older; exercise has never been my thing although I think it is fun to run medium distances (up to 10km).

I have gone through 6 surgeries, and have experienced extreme angst and pain — even with help from Opiat-like pain-killers (more specifically OxyContin and OxyNorm) and the pain-dissociative drug Ketamine (more specifically Ketalar). I am very grateful to be alive. I find joy in even the simplest of things, like being able to drink water or seeing trees outside the window. I have learned many things about medicine and my body, and I am curious by nature so I look forward to learn more. I hope to be able to draw strength from this incident, to help me prioritize better in my life. My loving wife Åsa has gone through a nightmare as a consequence of my diagnosis. At day she had to cope with daily life taking care of our wonderful little 1-year old daughter Ingrid and our 3-year old boy Alfred. All three of them had various degrees of strep throat with fever, caused by the same bacteria — and anyone with young kids know how intense that alone can be. She gave me strength over the phone. She kept friends and relatives up to date about what happened, with the phone ringing all the time. She worked to get information out from the hospital about my status, sometimes being rudely treated and just being hanged up on. Since I had only became worse and worse throughout the third operation, and the infection was still spreading, she at one time after a call with the doctor started to plan for a life without me.

My last operation were on Thursday January 2nd and I left hospital the same day. I’m writing this on the Saturday of January 4rd. I have regained access to my arm and hand and doing rehab to regain muscle control, while my body is healing. I’m doing relaxation exercises to control pain and relax muscles, so that I’m now rid of the strong drugs. I take antibiotics (more precisely Dalacin) and the common Paracetamol pain-killer together with on-demand use of an also common NSAID containing Ibuprofen. My wife and I were even out at a restaurant tonight.

Naturally, I now want to focus on getting well and spend time with my family. I’m not out of dangerous waters yet. Don’t expect anything from me in the communities and organization that I’m active in (i.e., GNU, Debian, IETF, Yubico), I will come back as energy, time and priorities permits.

Syndicated 2014-01-04 22:44:49 from Simon Josefsson's blog

Using Replicant on Samsung Galaxy S III

For the last half-year I have used CyanogenMod on an Nexus 4 as my main phone. Recently the touch functionality stopped working on parts of the display, and the glass on the back has started to crack. It seems modern phones are not built to last. For comparison, before the N4 I used a Nokia N900 for around 3 years without any hardware damages (in my drawer now, still working). A few weeks ago I started looking for a replacement. My experience with CyanogenMod had been good, but the number of proprietary blobs on the N4 concerned me. Finding something better wasn’t easy though, so I’m documenting my experience here.

My requirements were, briefly, that I wanted a phone that I could buy locally that had a free software community around it that produced a stable environment. I have modest requirements for things I wouldn’t give up on: telephony, data connection (3G), email (IMAP+SMTP), chat (XMPP), and a web browser. I like the philosophy and openness around the Firefox OS but the more I have read about it, it seems unlikely that it would deliver what I need today. In particular none of the devices capable of running Firefox OS appealed to me, and the state of email reading seemed unclear. I’m sure I’ll revisit Firefox OS as an alternative for me in the future.

As I had been happy with CyanogenMod, but concerned about its freeness, it felt natural to move on and test the more free software friendly project Replicant. Replicant only supports a small number of devices. After talking with people in the #replicant IRC channel, it seemed the Samsung S3 would be a decent choice for me. The Samsung S2 would have worked as well, but it cost almost as much as the S3 where I looked. Despite the large number of Samsung S3 devices out there, it seems the prices even for used devices are high (around 2500 SEK in Sweden, ~380 USD). I ended up buying a brand new one for 3200 SEK (~500 USD) which felt expensive, especially after recalling the recent \$199 sale for Nexus 4. Noticing that brand new Nexus 4 devices are still over 3000 SEK in Sweden comforted me a bit. I would have preferred a more robust phone, like the CAT B15, but the state of free software OSes on them seem unclear and I wanted something stable. So, enough about the background, let’s get started.

Building and installing Replicant on the device was straight forward. I followed the Replicant Samsung S3 Build instructions to build my own images. The only issue I had was that I had not set JAVA_HOME and the defaults were bad; make sure to set JAVA_HOME before building. I built everything on my Lenovo X201 running Debian Wheezy, with OpenJDK 6 as the Java implementation. Installing the newly built firmware was easy, I just followed the installation process documentation. I made sure to take a clockworkmod backup to an external SD card before wiping the old system. To get a really clean new device, I also re-formated /sdcard inside clockworkmod; I noticed there were some traces left of the old system there.

I spent about one week testing various configurations before settling on something I could use daily. A fair amount of time was spent looking into backup and restore options for Android devices. My idea was that I would take a backup of the apps I ran on the N4 and transfer them to the S3. The Android Debug Bridge (adb) has a backup/restore command, however it (intentionally) ignores apps marked as allowBackup=false which a number of apps has. It doesn’t seem possible to override that settings — so much for the freedom to backup your own device. I then discovered oandbackup. It can backup your entire system, saving each app (together with associated data) into a separate directory, for simple review and inspection before restore. You can do batch backups and batch restore. I couldn’t get it to automatically restore things, though, which would be neat for really automated re-installations (there is an open issue about this feature). After noticing that some apps did not like being moved from the N4 (running Android 4.2) to the S3 (running 4.0), I ended up installing most apps from scratch on a freshly installed Replicant. I use oandbackup to the external SD card so that I can quickly restore my phone. For backup/restore of SMS/MMS and Call Log, I use SMS Backup+ against my own IMAP server. Camera pictures are synced manually using adb when I am connected to my laptop.

There is a number of apps that deserve to be mentioned because they are what I use on a daily basis. All of them come via the free software market F-Droid. For email (IMAP/SMTP), I use K-9 Mail which is feature rich but still easy to use. For chat, I use Xabber. I use NewsBlur‘s free software app to read RSS flows. For two-factor authentication, I use Google Authenticator. I haven’t evaluated different PDF viewers, but the first one I tried (APV PDF Viewer) has worked fine so far. Handling a a synchronized address book and calendar deserve its own blog post because it is a challenging topic, but briefly, I’m currently using a combination of aCal and DAVdroid.

Finally, since Replicant is still work in progress, some words about stability and notes on what doesn’t work. This is probably the most interesting part if you are considering running Replicant on an S3 yourself. Overall system stability is flawless, I hadn’t had any crash or problem with the fundamental functionality (telephony, 3G, Camera). People have said graphics feels a bit laggy, but I cannot compare with the stock ROM and it doesn’t get in the way of daily use. First some notes about non-free aspects:

• Bluetooth doesn’t work by default. After installing /system/vendor/firmware/bcm4334.hcd (MD5 b6207104da0ca4a0b1da66448af7ed4c) pairing and testing with a Bluetooth headset worked fine.
• Front camera doesn’t work by default. After installing /system/vendor/firmware/fimc_is_fw.bin (MD5 52eeaf0889bc9206860075cd9b7f80b9and) and /system/vendor/firmware/setfile.bin (MD5 0e6fdeb378fb154c39fd508ae28eaf2a) it works. The extensions are *.bin but I don’t believe this code is executed on the main CPU.
• GPS doesn’t work by default. After installing /system/bin/gpsd (MD5 6757ed2e2a283259e67c62e6b2b9cfef), /system/lib/libsecril-client.so (MD5 a836df0f947d2aa2ef20dcb213317517), /system/lib/hw/gps.exynos4.so (MD5 1ea1d67f297dd52d59d40dbad9b02a0a) it works. This is code that runs on the main CPU, and even more alarming, it embeds a copy of OpenSSL and talks to various online servers for A-GPS, and is thus a likely (and probably not too challenging) attack vector for anyone wanting to remotely exploit any phone.
• Wifi doesn’t work, and I haven’t gotten this to work. There is a list of non-free S3 firmware on the Replicant wiki however my stock ROM did not ship with those files. I don’t believe any of the blobs run on the main CPU.
• NFC doesn’t work, and I haven’t gotten it to work. It seems the infrastructure for NFC is missing in Replicant 4.0, it doesn’t even expose the NFC hardware permission capability. This is quite unfortunate for me, since I daily work with YubiKey NEO and would have preferred to replace Google Authenticator with the YubiOATH that uses the NEO for OATH secret storage.

Some other observations:

• Panorama mode in the Camera crashes; see issue about it.
• There is a number of smaller graphical issues. I believe these are related to the EGL but haven’t understood the details. What I’ve noticed are the following issues. The task switcher doesn’t show mini screenshots of all running apps (the screenshots are just black). ZXing is not able to QR decode images (I’m told this is because Replicant uses a RGB color plane instead of the required YUV color plane). Video playback in the gallery is laggy to the point of being unusable. Video playback on Youtube in the default web browser works in full screen (not laggy), but not embedded in the webpage.
• MTP has been a bit unreliable, my main laptop is able to import photos, but another laptop (also running Debian Wheezy) just stalls when talking to it. This may be a host issue, I have experience similar issues with a Nexus 4 2nd generation device.

I am quite happy with the setup so far, and I will continue to use it as my primary phone.

Syndicated 2013-11-11 21:10:29 from Simon Josefsson's blog

34 older entries...

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!