Projects/Realm Crossover between KDCs - Revision history

Vanrein: /* Beyond Quantum Computing */

2018-02-14T11:08:36Z

‎Beyond Quantum Computing

Vanrein at 11:06, 14 February 2018

2018-02-14T11:06:07Z

Vanrein at 11:05, 14 February 2018

2018-02-14T11:05:06Z

Vanrein at 11:04, 14 February 2018

2018-02-14T11:04:07Z

Vanrein at 11:02, 14 February 2018

2018-02-14T11:02:40Z

Vanrein: /* Beyond Quantum Computing */

2018-02-14T11:00:55Z

‎Beyond Quantum Computing

Vanrein: /* Beyond Quantum Computing */

2018-02-14T10:58:17Z

‎Beyond Quantum Computing

Vanrein: /* Beyond Quantum Computing */

2018-02-14T10:57:22Z

‎Beyond Quantum Computing

Vanrein: /* Beyond Quantum Computing */

2018-02-14T10:56:29Z

‎Beyond Quantum Computing

Vanrein: /* Beyond Quantum Computing */

2018-02-10T21:51:30Z

‎Beyond Quantum Computing

← Older revision		Revision as of 11:08, 14 February 2018
Line 75:		Line 75:
	Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] — but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.		Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] — but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.

⚫	~~Using~~ KXOVER can utterly destroy ~~these~~ ~~advantages~~ for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.
		+	Our proposal for a TLS-KDH cipher suite, combining Kerberos authentication with ECDHE key agreement already withstands Quantum Computer attacks. It is an interesting pair with KXOVER, as the two allow Kerberos for many protocols across the Internet.
		+
		⚫	KXOVER can utterly destroy the resistence to Quantum Computing for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

	In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.		In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

@@ Line 7: / Line 7: @@
 * [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]
-We use '''KXOVER''' as a name for the Kerberos Realm Crossover protocol proposed on this page.  The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service, especially around schools and near opening and closing times of these schools.
+We use '''KXOVER''' as a name for the Kerberos Realm Crossover protocol proposed on this page.  The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service (for school children).
 ==Mechanics of the Project==

@@ Line 7: / Line 7: @@
 * [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]
-We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.  The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service, especially around schools and near opening and closing times of these schools.
+We use '''KXOVER''' as a name for the Kerberos Realm Crossover protocol proposed on this page.  The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service, especially around schools and near opening and closing times of these schools.
 ==Mechanics of the Project==
@@ Line 69: / Line 69: @@
 ==Related Projects==
-We propose KREALM-XOVER as a mechanism underneath TLS-KDH.  Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).
+We propose KXOVER as a mechanism underneath TLS-KDH.  Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).
 ==Beyond Quantum Computing==

@@ Line 7: / Line 7: @@
 * [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]
-We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.  The Dutch may pronounce KXOVER als "Klaar-Over".
+We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.  The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service, especially around schools and near opening and closing times of these schools.
 ==Mechanics of the Project==

@@ Line 7: / Line 7: @@
 * [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]
-We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.
+We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.  The Dutch may pronounce KXOVER als "Klaar-Over".
 ==Mechanics of the Project==
@@ Line 60: / Line 60: @@
 We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it.  To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs.  These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework.  (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)
 ==Comparison to Other Work==
@@ Line 80: / Line 70: @@
 We propose KREALM-XOVER as a mechanism underneath TLS-KDH.  Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).
 ==Specifications==

@@ Line 63: / Line 63: @@
 ==Beyond Quantum Computing==
-Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge.  We do need to make our twice twice as long as the customary 128 bit on account of [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) &mdash; but at least [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm), which is devastating for public key crypto, has no grip on it.
+Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge.  We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] &mdash; but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.
 Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm.  This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

@@ Line 69: / Line 69: @@
 In practice, we might assume that passive observers cannot scan all traffic that passes between all systems.  Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives.  There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us.  Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.
-In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted.
+In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted.  But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.
 ==Comparison to Other Work==

← Older revision		Revision as of 10:57, 14 February 2018
Line 68:		Line 68:

	In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.		In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.
		+
		+	In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted.

	==Comparison to Other Work==		==Comparison to Other Work==

@@ Line 63: / Line 63: @@
 ==Beyond Quantum Computing==
-Kerberos has an important advantage over public-key schemes, namely that it will hold up against quantum computers according to our current knowledge, as long as we double key sizes on account of [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) &mdash; but at least [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) has not grip on it.
+Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge, as long as we double key sizes on account of [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) &mdash; but at least [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) has not grip on it.
 Using KXOVER cat utterly destroy these advantages for any traffic between a differnet client realm and server realm.  This problem cannot be fixed in general.