Re: [Cfrg] considering new topics for CFRG

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: Sean Turner
> Sent: Wednesday, January 08, 2014 12:26 AM
> 
> 0) Could the CFRG get behind these recommendations for RSA-OAEP/PSS or
not:
> http://www.ietf.org/mail-archive/web/saag/current/msg04481.html
> http://www.ietf.org/mail-archive/web/saag/current/msg04482.html
>

Maybe CFRG should compare RSA-KEM to RSA-OAEP?  

Is there a signature analogue to RSA-KEM?

KEM is ISO 18033-2, but not in PKCS#1 (last I checked, which was long ago).

RSA-KEM looks cleaner and simpler, at least to me, though is perhaps less
efficient?

Since some in CFRG are interested in provable security, how do these two
compare on that front?  Especially, in the standard model?  A while back
several people (including) me found some theoretical impossibility results
against security proofs about RSA-OAEP and RSA-PSS in the standard model,
but since then I have mostly forgotten about that topic. These results
mostly concerned IND-CCA2 security.  I forget if these results apply to
RSA-KEM.  I vaguely recall some positive research results.


 
> 
> 1) Assuming RSA goes kaput, it seems like we're moving towards EC (am I
wrong
> here) then are these EC-based documents worth saying more about (e.g., in
the
> next version of the protocol use this or run away in fear):
> https://datatracker.ietf.org/doc/rfc6979/

Seems good.  In my own security analyses, one of the security arguments for
ECDSA needed the ephemeral keys to be message-constant to make the ROM work.
Maybe that was just a deficiency in my proof techniques.   I haven't
reviewed the specific algorithm in 6979, but I would be inclined to give a
slight edge to deterministic algs for ECDSA ephemeral keys.


> https://datatracker.ietf.org/doc/draft-peck-ecdhpop/

Seems good.  I had no idea the existing IETF POP excluded using ECDSA
signatures for ECDH keys. 

> https://datatracker.ietf.org/doc/draft-jivsov-ecc-compact/

I don't see a security problem.  Indeed, SEC1 permits similar filtering in
the key generation algorithm to facilitate accelerated verification of ECDSA
signatures.

The SEC1 encoding is really meant to be inserted wherever a definite octet
string is needed, mainly in ASN.1.  I believe the header byte was meant to
serve a dual tag-length role (that provided what was missing from the curve
id).  Maybe this I-D could propose something more specific to ASN.1.

I wonder if this compact representation might conflict with other proposals,
in that it becomes an untagged integer. 

> 
> 2) Is QKD something we need to start considering:
> http://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-00.txt
> http://tools.ietf.org/id/draft-ghernaouti-sfaxi-ppp-qkd-00.txt

I am more interested in the issue of whether quantum computing (for Shor's
algorithm) will, or even has, become feasible? I am not an expert in the
area, but am interested.

Of course, we can just go ahead and get prepared with proposals for
postquantum algs.  That's great to do, but still doesn't address the
question. I expect some may argue that asking this whole question just begs
pointless speculation, on the grounds that if your adversary (soon) has a
QC, then you should have spent your time switching to PQ rather than
thinking about whether the adversary had a QC.  In other words, I'm
expecting some may say that consideration of postquantum crypto is perfectly
reasonable, but asking about the existence of a quantum computer is
pointless.  

But I think it is okay for CFRG to consider it, and, nay, even try to boldly
quantify these, say with likelihood 2^(-64) of some well-defined claim,
calculated via a series of estimates.  The status quo is to just claim that
algorithm X with key size provides 128 bit security, whatever that means,
perhaps adding the exclusion against quantum computers.  Adding an estimated
likelihood of a quantum computer gives a more meaning of what kind of
security is being claimed.  Maybe the postquantum researchers already have
made such an estimate, as part of an effort to justify a switch to
postquantum.  

I would understand if the CFRG chairs deem this out of scope for CFRG.  If
so, I hope that somebody could suggest to me off-list an alternative forum.

An informal, perhaps dubious, argument that comes to my mind is the
following.  The most likely party to have a quantum computer is a large
nation.  If they had such a thing, then they could break almost all IETF
crypto, except pre-shared key based stuff, and wouldn't have to resort to
any other chicanery.  But reports are now suggesting the latter.  Well, the
chicanery could all be just a cover-up ruse.  Or more realistically, maybe
the quantum computer is kept on reserve, and more mundane cryptanalysis is
used on a daily basis, maybe because it is cheaper.  Still, why not just lay
little lower, if a QC is available? Anyway, the loose inference I'm drawing
is that a quantum computer does not yet exist, and further that the most
likely parties to have one do not anticipate being able to have one in the
near future.  Well, this argument does not give any kind of quantified
likelihood. If I had to dead-reckon a likelihood, I'd make a wildly
different number every time, but most of them would be above 2^(-128),
unfortunately.  

I wonder if others have more substantial arguments. 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.