headers
Robert J. Hansen | 27 May 2012 13:10
Favicon

RFE: max-*-size and strip-photo-uids

At present, there are no credible reports of the keyserver network being
used to distribute illegal data.  I'd like to repeat that: at present
there are *NO* credible reports of the keyserver network being used to
distribute illegal data.  Please don't think I'm crying that the sky is
falling, because it clearly hasn't fallen and we might go decades more
without the sky falling.

That said, the best time to prepare for a crisis is before the crisis hits.

I would like to propose two feature requests for SKS.  One (which I'll
just call the "max-*-size" feature request) will limit the maximum size
of a user ID, user attribute, subkey, signature, etc.: anything larger
than this will not be accepted into the database nor shared with clients
or other servers.  This will help prevent the network from being used to
distribute arbitrary binary data, although it could still be evaded by,
e.g., breaking a large binary into a bunch of signatures and placing
them on the certificate in order, so that they can be reassembled on the
other side.

The second (which I'll call the "strip-photo-uids" feature request) will
strip all photo UIDs regardless of size.  Again, this is not an ironclad
solution: dedicated malcontents will just encode their images some other
way.

*These feature requests have clear, obvious downsides.*  (Not the least
of which is they won't work particularly well.)  I don't believe either
of these features is ready for implementation, but I hope that if we
talk about it for a while we might be able to reach a better idea that
will more appropriately address our needs.
(Continue reading)

Permalink | Reply |
headers
Robert J. Hansen | 27 May 2012 13:45
Favicon

Re: RFE: max-*-size and strip-photo-uids

On 5/27/12 7:10 AM, Robert J. Hansen wrote:
> *These feature requests have clear, obvious downsides.*  (Not the least
> of which is they won't work particularly well.)

So, the first question is -- what would be necessary for a solution to
work well?

The brute force and overkill approach: sanity-check each imported
certificate to ensure that the subkeys on the certificate are legitimate
cryptographic keys.

Note: this is barking madness.  If I give you a block of bits and say
this represents two numbers, the first being the product of two large
primes and the second number coprime to the first -- e.g., the (n, e)
tuple of an RSA public key -- the only way to prove it's a legitimate
public key would be to factor the first number and ensure that pq=n with
p and q prime, and that e is coprime to n.  If the only way to prove
that a block of data is a correct RSA key is to break RSA, then we're
absolutely screwed.

So much for the brute force and overkill approach.  We simply cannot
check to ensure that an RSA public key is good.  This may leave the door
open to checking whether an RSA public key is obviously *bad*.

To check for obviously bad keys, we could do trial divisions on all the
primes up to, say, 10,000.  A naive encoding of binary data onto a
purported RSA key would likely have a factor somewhere within that
range.  Presto, we have a way to detect bad RSA keys.

Unfortunately, it's completely bogus.  Someone could simply do a naive
(Continue reading)

Permalink | Reply |
headers
Jeffrey Johnson | 27 May 2012 15:02

Re: RFE: max-*-size and strip-photo-uids


On May 27, 2012, at 7:45 AM, Robert J. Hansen wrote:

> On 5/27/12 7:10 AM, Robert J. Hansen wrote:
>> *These feature requests have clear, obvious downsides.*  (Not the least
>> of which is they won't work particularly well.)
> 
> So, the first question is -- what would be necessary for a solution to
> work well?
> 
> The brute force and overkill approach: sanity-check each imported
> certificate to ensure that the subkeys on the certificate are legitimate
> cryptographic keys.
> 
> Note: this is barking madness.  If I give you a block of bits and say
> this represents two numbers, the first being the product of two large
> primes and the second number coprime to the first -- e.g., the (n, e)
> tuple of an RSA public key -- the only way to prove it's a legitimate
> public key would be to factor the first number and ensure that pq=n with
> p and q prime, and that e is coprime to n.  If the only way to prove
> that a block of data is a correct RSA key is to break RSA, then we're
> absolutely screwed.
> 
> So much for the brute force and overkill approach.  We simply cannot
> check to ensure that an RSA public key is good.  This may leave the door
> open to checking whether an RSA public key is obviously *bad*.
> 
> To check for obviously bad keys, we could do trial divisions on all the
> primes up to, say, 10,000.  A naive encoding of binary data onto a
> purported RSA key would likely have a factor somewhere within that
(Continue reading)

Permalink | Reply |

Gmane