gnupg - How to use Unicode in "Real Name" bit of key?

08
2014-07
  • Thanatos

    GPG appears to support Unicode, but I can't get it to actually work

    % gpg --utf8-strings --display-charset utf-8 --edit-key [email protected]
    gpg (GnuPG) 1.4.15; Copyright (C) 2013 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: key xxxxxxxx: duplicated user ID detected - merged
    Secret key is available.
    
    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
    pub  4096R/xxxxxxxx  created: 2014-02-20  expires: never       usage: SC
                         trust: ultimate      validity: ultimate
    sub  4096R/xxxxxxxx  created: 2014-02-20  expires: never       usage: E
    [ultimate] (1). King George \xe2\xa3\x20<[email protected]>
    
    gpg> uid
    
    pub  4096R/xxxxxxxx  created: 2014-02-20  expires: never       usage: SC
                         trust: ultimate      validity: ultimate
    sub  4096R/xxxxxxxx  created: 2014-02-20  expires: never       usage: E
    [ultimate] (1). King George \xe2\xa3\x20<[email protected]>
    
    gpg> adduid
    Real name: King George Ⅳ      ### I type this.
    Email address: [email protected]
    Comment:
    You are using the `utf-8' character set.
    You selected this USER-ID:
        "King George � <[email protected]>"    ### Terminal notes corruption.
    
    Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
    
    You need a passphrase to unlock the secret key for
    user: "King George \xe2\xa3\x20<[email protected]>"
    4096-bit RSA key, ID xxxxxxxx, created 2014-02-20
    
    
    pub  4096R/xxxxxxxx  created: 2014-02-20  expires: never       usage: SC
                         trust: ultimate      validity: ultimate
    sub  4096R/xxxxxxxx  created: 2014-02-20  expires: never       usage: E
    [ultimate] (1)  King George \xe2\xa3\x20<[email protected]>
    [ultimate] (2). King George \xe2\xa3\x20<[email protected]>  ### That's not correct UTF-8.
    
    • My terminal is set to use UTF-8.
    • LANG=en_US.UTF-8

    Note the bottom: The UTF-8 sequence isn't correct, but it's close! The middle octet of the three-byte sequence that should be there is missing. I doubt there's anything I could do to cause the middle octet to drop, so what's going on here?

  • Answers
    Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

    Related Question

    gnupg - gpg: WARNING: message was not integrity protected
  • Darius

    I'm a little confused as what this means.

    What's happened is that someone has encrypted a message for me using my public key, and signed it with their private key - as per usual.

    Next, I decrypt the message...

    -bash-3.2$ gpg --decrypt /tmp/det_prod_cred.txt.asc 
    gpg: encrypted with 2048-bit ELG-E key, ID 2E52ED13, created 2001-10-15
          "XXXXXXX1"
    gpg: encrypted with 4096-bit RSA key, ID 0BB096A1, created 2009-08-12
          "XXXXXXX2"
    username = XXXXXXXXXX3  
    password = XXXXXXXXXX4
    gpg: Signature made Wed 12 Aug 2009 15:47:17 EST using DSA key ID C2E36CC8
    gpg: Good signature from "17155x01"
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: 826A E10D 8AAB 49A0 E9B6  0478 3A70 240F C2E3 6CC8
    gpg: WARNING: message was not integrity protected
    

    ...I know the message is verbose and I probably should understand what it is getting at - but I'm not confident that I do - so any further explanation on this would be appreciated.

    Is it basically saying that the person who has signed this message, does not pass the rules defined in my trustdb?

    $ gpg --update-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
    

    While...

    $ gpg --edit-key 0xC2E36CC8
    gpg (GnuPG) 1.4.5; Copyright (C) 2006 Free Software Foundation, Inc.
    This program comes with ABSOLUTELY NO WARRANTY.
    This is free software, and you are welcome to redistribute it
    under certain conditions. See the file COPYING for details.
    
    
    pub  1024D/C2E36CC8  created: 2001-10-15  expires: never       usage: SCA 
                         trust: marginal      validity: unknown
    sub  2048g/2E52ED13  created: 2001-10-15  expires: never       usage: E   
    [ unknown] (1). 17155x01
    

    Notice I've only marginally trusted the key, if I fully trust it (which I can't), will the problem disappear?


  • Related Answers
  • Sam Stokes

    There are two different warnings here, and I think the other responders are assuming the one is caused by the other.

    I assume the "message was not integrity protected" warning is your main concern, since that's the title of this question. There seem to be several things that can cause that, but the one I just encountered is when GPG's "MDC protection" feature isn't enabled. I don't know what it stands for, but apparently it's a message integrity check that proves the message hasn't been tampered with.

    Apparently this feature is on by default, but gets disabled if any of the recipient keys don't specify they support it. So I just got the warning for the first time when adding a new recipient to a file I'd previously been encrypting only to myself, presumably because the new recipient didn't say they supported MDC.

    I got the warning to go away by adding --force-mdc to my GPG command. I haven't yet discovered whether this prevents the new recipient from decrypting the message...

    I'm pretty sure the other warning, about the key not being trusted, is unrelated to the "not integrity protected" warning.

  • Noon Silk

    In gpg, you don't yet 'trust' the sender. So even though it's from yourmate@whatever, you haven't set their trust level in gpg to whatever it needs to be to not get that message :)

    At least that's what I think; could be wrong. GPG docs should help though.

  • Broam

    What silky said: you don't trust the sender.

    However you may also need to sign the sender's key.