Re: [Sks-devel] peer request for pgp.uplinklabs.net
On 31/08/16 06:12, Steven Noonan wrote: > Resending this message with a key that isn't revoked. Doh! Except now, because it's an ECC key, nobody can verify your mail unless they're running GPG 2.1... :-) Cheers, Chris -- Chris Boot bo...@bootc.net signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] peer request for pgp.uplinklabs.net
apt-get upgrade or the alternative on your distro helps ;) On August 31, 2016 10:29:48 AM GMT+02:00, Chris Boot wrote: >On 31/08/16 06:12, Steven Noonan wrote: >> Resending this message with a key that isn't revoked. Doh! > >Except now, because it's an ECC key, nobody can verify your mail unless >they're running GPG 2.1... :-) > >Cheers, >Chris > >-- >Chris Boot >bo...@bootc.net > > > > > >___ >Sks-devel mailing list >Sks-devel@nongnu.org >https://lists.nongnu.org/mailman/listinfo/sks-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] peer request for pgp.uplinklabs.net
GnuPG 2.1 is not available on Debian stable (jessie) at all at the moment. And no, 3rd party repos are not the answer for this, particularly not for sensitive crypto software. On 31/08/16 09:50, Hillebrand van de Groep wrote: > apt-get upgrade or the alternative on your distro helps ;) > > On August 31, 2016 10:29:48 AM GMT+02:00, Chris Boot > wrote: > > On 31/08/16 06:12, Steven Noonan wrote: > > Resending this message with a key that isn't revoked. Doh! > > > Except now, because it's an ECC key, nobody can verify your mail unless > they're running GPG 2.1... :-) > > Cheers, > Chris > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Chris Boot bo...@bootc.net ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] peer request for pgp.uplinklabs.net
I'm sceptical of the utility of ECC keys personally. They were first proposed as a way of reducing work and storage space (because the space of usable ECC keys is more compact than the sparsely distributed RSA primes). But they've taken so long to catch on that technology advancement has made their original justification largely irrelevant (the only exception to my knowledge being DNSSEC, where signature length restrictions are still important). And because the ECC keyspace is more efficiently packed, it is theoretically *more* susceptible to quantum attacks. It's notable that the NSA no longer recommends ECC keys. Personally, I'm sticking to RSA until post-quantum encryption is ready. :-) A > On 31 Aug 2016, at 10:00, Chris Boot wrote: > > GnuPG 2.1 is not available on Debian stable (jessie) at all at the > moment. And no, 3rd party repos are not the answer for this, > particularly not for sensitive crypto software. > >> On 31/08/16 09:50, Hillebrand van de Groep wrote: >> apt-get upgrade or the alternative on your distro helps ;) >> >> On August 31, 2016 10:29:48 AM GMT+02:00, Chris Boot >> wrote: >> >>On 31/08/16 06:12, Steven Noonan wrote: >> >>Resending this message with a key that isn't revoked. Doh! >> >> >>Except now, because it's an ECC key, nobody can verify your mail unless >>they're running GPG 2.1... :-) >> >>Cheers, >>Chris >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > -- > Chris Boot > bo...@bootc.net > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Sync issues with sks 1.1.6
Attempted doing a dump and rebuild of my database from that, but it didn't help
with this problem. Still sees those same two keys out of sync:
==> recon.log <==
2016-08-31 04:37:02 Added 1 hash-updates. Caught up to 1472643422.340101
2016-08-31 04:37:58 error in callback.: Sys_error("Connection
reset by peer")
2016-08-31 04:38:56 2 hashes recovered from
2016-08-31 04:38:56 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:38:56 AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:38:56 Requesting 2 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:38:56 2 keys received
==> db.log <==
2016-08-31 04:38:56 Applying 0 changes
==> recon.log <==
2016-08-31 04:39:59 2 hashes recovered from
2016-08-31 04:39:59 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:39:59 AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:40:00 Requesting 2 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:40:01 2 keys received
==> db.log <==
2016-08-31 04:40:01 Applying 0 changes
==> recon.log <==
2016-08-31 04:40:54 4 hashes recovered from
2016-08-31 04:40:54 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:40:54 4C9895E31B8E52499BADB8F03A629E5F
2016-08-31 04:40:54 9C9A6B3836B3431317E1F507EBE02E69
2016-08-31 04:40:54 AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:41:04 Requesting 4 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:04 4 keys received
==> db.log <==
2016-08-31 04:41:04 Applying 0 changes
==> recon.log <==
2016-08-31 04:41:13 2 hashes recovered from
2016-08-31 04:41:13 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:13 AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:41:23 Requesting 2 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:23 2 keys received
==> db.log <==
2016-08-31 04:41:23 Applying 0 changes
Any idea what is happening here?
On 30/08/16 23:03, Steven Noonan wrote:
> I've noticed that SKS seems to be having trouble staying synced. I've seen
> it attempt to recover the same two hashes several times in a row, but
> apparently somehow not succeeding. Below is after a fresh restart of both
> the DB and recon services:
>
> ==> db.log <==
> 2016-08-30 22:47:47 Calculating DB stats
> 2016-08-30 22:47:49 Done calculating DB stats
> 2016-08-30 22:47:49 Database opened
> 2016-08-30 22:47:49 Applied filters: yminsky.dedup, yminsky.merge
> 2016-08-30 22:52:38 Applying 4 changes
> 2016-08-30 22:52:38 Adding hash 5A43BA76C61920AD131BEB229F01CE77
> 2016-08-30 22:52:38 Adding hash 5E74523E56488B6FE65FAA3C584AAABF
> 2016-08-30 22:52:38 Adding hash 98CD7C824D3BEEC91B858BF4B53BE479
> 2016-08-30 22:52:38 Adding hash EEC18519F506D79394196B5F58A1A9F0
> 2016-08-30 22:52:39 Sending LogResp size 4
>
> ==> recon.log <==
> 2016-08-30 22:52:37 5E74523E56488B6FE65FAA3C584AAABF
> 2016-08-30 22:52:37 98CD7C824D3BEEC91B858BF4B53BE479
> 2016-08-30 22:52:37 AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:52:37 EEC18519F506D79394196B5F58A1A9F0
> 2016-08-30 22:52:38 Requesting 6 missing keys from [163.172.29.20]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:52:38 6 keys received
> 2016-08-30 22:52:39 Added 4 hash-updates. Caught up to 1472622758.953643
> 2016-08-30 22:53:57 2 hashes recovered from [184.105.143.180]:11371>
> 2016-08-30 22:53:57 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:53:57 AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:54:07 Requesting 2 missing keys from [184.105.143.180]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:54:07 2 keys received
>
> ==> db.log <==
> 2016-08-30 22:54:07 Applying 0 changes
>
> ==> recon.log <==
> 2016-08-30 22:55:14 2 hashes recovered from
> 2016-08-30 22:55:14 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:55:14 AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:55:17 Reconciliation attempt from [78.47.176.74]:51680> while gossip disabled. Ignoring.
> 2016-08-30 22:55:24 Requesting 2 missing keys from [78.46.223.54]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:55:24 2 keys received
>
> ==> db.log <==
> 2016-08-30 22:55:24 Applying 0 changes
>
> ==> recon.log <==
> 2016-08-30 22:57:47 4 hashes recovered from
> 2016-08-30 22:57:47 1411D6DD875ABB5E89B4CB389B3C3487
> 2016-08-30 22:57:47 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:57:47 78C2581DB360C4EAD780866602AE2BFF
> 2016-08-30 22:57:47 AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:57:48 Requesting 4 missing keys from [163.172.29.20]:11371>, starting with 1411D6DD875ABB5E89B4CB389B3C3487
> 2016-08-30 22:57:48 4 keys received
>
> ==> db.log <==
> 2016-08-30 22:57:48 Applying 2 changes
> 2016-08-30 22:57:48 Adding hash 1411D6DD875ABB5E89B4CB389B3C3487
> 2016-08-30 22:57:48 Adding hash 78C2581DB360C4EAD780866602AE2BFF
> 2016-08-30 22:57:49 Sending LogResp size 2
>
> ==> recon.log <==
> 2016-08-30 22:57:49 Added 2 hash-updates. Caught
Re: [Sks-devel] Sync issues with sks 1.1.6
On 31/08/16 07:07, Christoph Egger wrote: > Hi! > > Steven Noonan writes: >> Attempted doing a dump and rebuild of my database from that, but it didn't >> help >> with this problem. Still sees those same two keys out of sync: > > Wild guess: ECC keys and your peer doesn't understand them and sends you > some data your server doesn't like > > Christoph > Ah. Could that be what's making some of the bits on my server seem to stay on my server and apparently not replicate to other SKS hosts? Maybe I don't entirely understand the recon.log file, but it seems like it talks a bunch about pulling hashes from other hosts but doesnt log anything about sending them out. -- F8D5 F819 8DEB 0703 1565 1A90 7EAC B44B A7B3 0DB9 I am tycho (https://keybase.io/tycho) on keybase. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Sync issues with sks 1.1.6
Hi! Steven Noonan writes: > Attempted doing a dump and rebuild of my database from that, but it didn't > help > with this problem. Still sees those same two keys out of sync: Wild guess: ECC keys and your peer doesn't understand them and sends you some data your server doesn't like Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Sync issues with sks 1.1.6
Steven Noonan writes: > On 31/08/16 07:07, Christoph Egger wrote: >> Steven Noonan writes: >>> Attempted doing a dump and rebuild of my database from that, but it didn't >>> help >>> with this problem. Still sees those same two keys out of sync: >> >> Wild guess: ECC keys and your peer doesn't understand them and sends you >> some data your server doesn't like > > Ah. Could that be what's making some of the bits on my server seem to stay on > my server and apparently not replicate to other SKS hosts? > > Maybe I don't entirely understand the recon.log file, but it seems like it > talks a bunch about pulling hashes from other hosts but doesnt log anything > about sending them out. Well it doen't know really. The other side "locally" calculates the things it lacks and gets them via hkp Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] peer request for pgp.uplinklabs.net
Andrew Gallagher dijo [Wed, Aug 31, 2016 at 10:14:01AM +0100]: > I'm sceptical of the utility of ECC keys personally. They were first > proposed as a way of reducing work and storage space (because the > space of usable ECC keys is more compact than the sparsely > distributed RSA primes). But they've taken so long to catch on that > technology advancement has made their original justification largely > irrelevant (the only exception to my knowledge being DNSSEC, where > signature length restrictions are still important). And because the > ECC keyspace is more efficiently packed, it is theoretically *more* > susceptible to quantum attacks. I'm far from a worthy crypto geek myself, but still — Storage space is not the decisive issue; storing a million 4096-bit keys is only an order of magnitude more than storing a million 256-bit keys (the same proportion would naturally apply for a single key), and information appended to the keys themselves (such as photo attributes and the signatures that constitute the web of trust) make the difference quite unnoticeable. What is really a difference is the arithmetic operations upon which they are based: Encryption and decryption under RSA are based on long series of multiplications (or rather, huge exponentiation). Under ECC, the operations are "just" series of additions. Adding is way cheaper for a computer than multiplying, so your hardware will be able to perform many, many more cryptographic operations with ECC than with RSA. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] peer request for pgp.uplinklabs.net
Gunnar Wolf writes: > Andrew Gallagher dijo [Wed, Aug 31, 2016 at 10:14:01AM +0100]: >> I'm sceptical of the utility of ECC keys personally. They were first >> proposed as a way of reducing work and storage space (because the >> space of usable ECC keys is more compact than the sparsely >> distributed RSA primes). But they've taken so long to catch on that >> technology advancement has made their original justification largely >> irrelevant (the only exception to my knowledge being DNSSEC, where >> signature length restrictions are still important). And because the >> ECC keyspace is more efficiently packed, it is theoretically *more* >> susceptible to quantum attacks. > > I'm far from a worthy crypto geek myself, but still — Storage space is > not the decisive issue; storing a million 4096-bit keys is only an > order of magnitude more than storing a million 256-bit keys (the same > proportion would naturally apply for a single key), and information > appended to the keys themselves (such as photo attributes and the > signatures that constitute the web of trust) make the difference quite > unnoticeable. It also affects the size of each signature, certificate | :signature packet: algo 22, keyid 1BB721A4B254D8E1 | version 4, created 1472657540, md5len 0, sigclass 0x00 | digest algo 8, begin of digest fd 82 | hashed subpkt 2 len 4 (sig created 2016-08-31) | subpkt 16 len 8 (issuer key ID 1BB721A4B254D8E1) | data: [256 bits] | data: [256 bits] vs | :signature packet: algo 1, keyid ABFFEDB24008C6F9 | version 4, created 1472657570, md5len 0, sigclass 0x00 | digest algo 8, begin of digest c8 06 | hashed subpkt 2 len 4 (sig created 2016-08-31) | subpkt 16 len 8 (issuer key ID ABFFEDB24008C6F9) | data: [4095 bits] Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] peer request for pgp.uplinklabs.net
On 31/08/16 16:18, Gunnar Wolf wrote: > Adding is way cheaper > for a computer than multiplying, so your hardware will be able to > perform many, many more cryptographic operations with ECC than with > RSA. That's a good argument for using EECDH in TLS, which is fair enough - with ephemeral keys it's legitimate to prioritise speed. But it's less applicable to PGP or x509, where the processing cost of the asym sig/crypt is comparatively small. A signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released
On Mon, Aug 08, 2016 at 03:45:12PM -0400, Daniel Kahn Gillmor wrote: > I've prepared a jessie-backports package that i'm running on > zimmermann.mayfirst.org as well. As soon as 1.1.6-1 makes it into > testing, i'll push it into jessie-backports. Hi, I'm sure you're busy but the above makes it sound like the process of getting 1.1.6 into jessie-backports would be fairly quick and simple. It's been in testing for a while now but still no sign of it in jessie-backports. Is there any particular reason for the delay? Thanks William signature.asc Description: Digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released
Hi William-- On Wed 2016-08-31 13:26:24 -0400, William Hay wrote: > On Mon, Aug 08, 2016 at 03:45:12PM -0400, Daniel Kahn Gillmor wrote: >> I've prepared a jessie-backports package that i'm running on >> zimmermann.mayfirst.org as well. As soon as 1.1.6-1 makes it into >> testing, i'll push it into jessie-backports. > > I'm sure you're busy but the above makes it sound like the process > of getting 1.1.6 into jessie-backports would be fairly quick and > simple. It's been in testing for a while now but still no sign of it > in jessie-backports. Is there any particular reason for the delay? Good call, i've gone ahead with an upload. hopefully i got all the logistics right :) If i got something wrong with this upload, i might wait another 4 days for my fix to https://bugs.debian.org/835982 to make it into testing and upload that as a backport instead. thanks for the nudge! --dkg signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released
Sounds like a good idea from reading over the BTS report. If someone setting up a new server were to grab that it would no doubt cause issues. Is the package still forcing the backup and re-import on upgrade? I know that is what took one of my servers out when I upgraded as they don't have the space to do so. I'd rather just blow away the DB and let my SaltStack deployment re-import a fresh keydump. On 8/31/2016 2:51 PM, Daniel Kahn Gillmor wrote: > Hi William-- > > On Wed 2016-08-31 13:26:24 -0400, William Hay wrote: >> On Mon, Aug 08, 2016 at 03:45:12PM -0400, Daniel Kahn Gillmor wrote: >>> I've prepared a jessie-backports package that i'm running on >>> zimmermann.mayfirst.org as well. As soon as 1.1.6-1 makes it into >>> testing, i'll push it into jessie-backports. >> I'm sure you're busy but the above makes it sound like the process >> of getting 1.1.6 into jessie-backports would be fairly quick and >> simple. It's been in testing for a while now but still no sign of it >> in jessie-backports. Is there any particular reason for the delay? > Good call, i've gone ahead with an upload. hopefully i got all the > logistics right :) > > If i got something wrong with this upload, i might wait another 4 days > for my fix to https://bugs.debian.org/835982 to make it into testing and > upload that as a backport instead. > > thanks for the nudge! > >--dkg > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released
On Wed 2016-08-31 15:44:20 -0400, Jeremy T. Bouse wrote: > Is the package still forcing the backup and re-import on upgrade? I > know that is what took one of my servers out when I upgraded as they > don't have the space to do so. I'd rather just blow away the DB and > let my SaltStack deployment re-import a fresh keydump. I believe it only does that if the underlying bdb version has changed, in which case it's really necessary. If it's forcing an upgrade on you when it shouldn't need to, please report it as a bug in the debian BTS. Regards, --dkg signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
