Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released

[Daniel Kahn Gillmor]

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

Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released

[Daniel Kahn Gillmor]

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

[William Hay]

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] peer request for pgp.uplinklabs.net

[Andrew Gallagher]

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] peer request for pgp.uplinklabs.net

[Christoph Egger]

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

[Gunnar Wolf]

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] Sync issues with sks 1.1.6

[Christoph Egger]

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] Sync issues with sks 1.1.6

[Steven Noonan]

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] peer request for pgp.uplinklabs.net

[Chris Boot]

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

[Hillebrand van de Groep]

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

[Chris Boot]

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

[Sks-devel] Sync issues with sks 1.1.6

[Steven Noonan]

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 , 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 
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 , 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  while gossip disabled. Ignoring.
2016-08-30 22:55:24 Requesting 2 missing keys from , 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 , 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 up to 1472623068.709972

For some reason the DB doesn't appear to want to add the hashes
3C6042D474F66ED92D763E76BEAF6DE4 and AA13C5E2197D1D97DF7061D30B954060.
It's also mentioning "while gossip disabled" in the recon log, but I'm
not sure I understand what conditions cause that to happen. I don't have
a 'dontgossip' line in my sksconf or anything like that. 

-- 
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