Re: [Qirg] QKD in OpenSSL

[Rodney Van Meter <[e-mail]>]

DoS may indeed be the attackers goal, but it could alternatively be an attempt to steal some bits of the key without being detected.  QKD in that sense is a battle of wits^H^H^H^Hstatistics between the attacker and the defender.  I’m not actually an expert on the limits of eavesdropper detection in the presence of noise, privacy amplification, etc.

We can certainly talk about this during the open mic portion of tomorrow’s meeting if you’re in SIN or joining remotely.

Note that I consider integration of Quantum Internet services into the Internet to be within scope for QIRG, but the specifics of security arguments certainly require expertise from the Security Area folks, and could arguably be outside the immediate scope of QIRG.

See you tomorrow.

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[e-mail]



> On Nov 18, 2019, at 18:34, Diego R. Lopez <[e-mail]> wrote:
> 
> Hi Bruno,
>  
> It looks I’m becoming the “physical argument” guy in the group, but the fact is that QKD (and I guess quantum communication at large) has to do with physical effects, and we have not achieved (not sure if we eve would) the levels of abstraction and virtualization we see in classical digital environments. So observation in QKD implies physical access, and therefore the capacity of direct physical interference. And, FWIW,  cutting a fiber is always cheaper than any quantum-level observations…
>  
> Be goode,
>  
> --
> "Esta vez no fallaremos, Doctor Infierno"
>  
> Dr Diego R. Lopez
> Telefonica I+D
> https://www.linkedin.com/in/dr2lopez/ <https://www.linkedin.com/in/dr2lopez/> 
>  
> e-mail: [e-mail] <mailto:[e-mail]>
> Tel:         [phone]
> Mobile:  [phone]
> ----------------------------------
>  
> On 18/11/2019, 15:08, "Qirg on behalf of Bruno Rijsman" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:
>  
> Yes, this is something that has always bothered me about QKD.
>  
> In classical key exchange (e.g. Diffie-Hellman), if an eavesdropper Eve passively observes a key exchange (e.g. by passively tapping a fiber), then Alice and Bob neither need to know nor care that Eve is doing that. Alice and Bob can just use the key “knowing” that Eve (if she is present) cannot determine the shared key by just observing the key exchange (assuming Eve doesn’t have a quantum computer).
>  
> But in QKD, if Eve passively observes the key exchange, then Alice and Bob will detect that Eve has “observed" the key exchange and by doing so Eve has invalidated the key exchange. Hence, Alice and Bob cannot use the shared key and must start over or fall back to classical key exchange, just because Eve was there “observing" the key exchange.
>  
> Just as you say, just “passively observing” a fiber constitutes a Denial-of-Service attack.
>  
> Of course, the terminology “passively observing” is kind of meaningless in quantum mechanics, because observing = interfering. 
>  
> But still, this bothered me a lot, and made me feel that QKD is more “vulnerable” than classical key exchange to DoS attacks.
>  
> The standard defense that I always read in the QKD literature is that if Eve is in a position to passively monitor a link, then she is also in a position to initiate a DoS attack by simply cutting the fiber. So, the argument goes, QKD is no more vulnerable to a DoS attack than classical key exchange.  I am not sure if I agree with that — it does not feel quite right to me.
>  
> — Bruno
> 
> 
>> On Nov 18, 2019, at 7:00 AM, Rodney Van Meter <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>> Very cool. 
>>  
>> You might check out some of the work we did five years ago that never made it to RFC.
>> https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 <https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01>
>>  
>> One interesting, and controversial, topic is what to do when an eavesdropper *does* interfere with a QKD connection.  It’s a great, and easy, DOS attack.  So, should the rekeying stop, and the connection depending on the rekeying be killed when the key lifetime expires?  Or should there be a fallback mechanism of potentially lower security?
>>  
>> This is more of an issue for IPsec, which has rekeying and explicit lifetimes, than for SSL.
>>  
>> Rodney Van Meter
>> Professor, Faculty of Environment and Information Studies
>> Keio University, Japan
>> [e-mail] <mailto:[e-mail]>
>>  
>>  
>> 
>> 
>>> On Nov 13, 2019, at 21:47, Bruno Rijsman <[e-mail] <mailto:[e-mail]>> wrote:
>>>  
>>> For those interested, I just posted a report on how we added support for Quantum Key Distribution (QKD) to OpenSSL during the RIPE Pan-European Hackathon at QuTech last week. 
>>>  
>>> http://bit.ly/openssl-qkd <http://bit.ly/openssl-qkd>
>>>  
>>> — Bruno
>>> _______________________________________________
>>> Qirg mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>
>>  
> 
>  
> 
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
> _______________________________________________
> Qirg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>