SSL/TLS Vulnerabilities: LuckyThirteen & BEAST - Revision history

SLazar at 17:49, 10 November 2024

2024-11-10T17:49:31Z

Show changes

SLazar at 17:43, 10 November 2024

2024-11-10T17:43:40Z

Show changes

SLazar: SLazar moved page Lucky 13 to SSL/TLS Vulnerabilities: LuckyThirteen & BEAST

2024-11-10T15:51:58Z

SLazar moved page Lucky 13 to SSL/TLS Vulnerabilities: LuckyThirteen & BEAST

← Older revision		Revision as of 15:51, 10 November 2024
(No difference)

NKirnbauer: gendering

2024-10-22T16:41:18Z

gendering

← Older revision		Revision as of 16:41, 22 October 2024
Line 76:		Line 76:
	* Send it.		* Send it.
	* On receipt of the message and the MAC, the receiver feeds the received message and the shared secret key K into the MAC algorithm and re-computes the MAC value.		* On receipt of the message and the MAC, the receiver feeds the received message and the shared secret key K into the MAC algorithm and re-computes the MAC value.
	* The receiver now checks equality of freshly computed MAC with the MAC received from the sender. If they match, then the receiver accepts the message and assures ~~himself~~ that the message has been sent by the intended sender.		* The receiver now checks equality of freshly computed MAC with the MAC received from the sender. If they match, then the receiver accepts the message and assures themself that the message has been sent by the intended sender.

	[[File:MAC-then-encrypt.png]]		[[File:MAC-then-encrypt.png]]


	== DTLS Record Protocol ==		== DTLS Record Protocol ==

NKirnbauer: merging similar articles

2024-10-22T16:40:18Z

merging similar articles

Show changes

NKirnbauer: link that doesnt exist

2024-10-22T14:42:02Z

link that doesnt exist

← Older revision		Revision as of 14:42, 22 October 2024
Line 1:		Line 1:

	Lucky 13 is a timing attack on TLS/DTLS ~~[https://wiki.elvis.science/index.php/~~protocol ~~protocol]~~ discovered in 2012 by Nadhem AlFardan and [http://web.archive.org/web/20220531081741/https://www.isg.rhul.ac.uk/~kp/ Kenny Paterson]. In 2013, they published their findings and released their [http://web.archive.org/web/20190414143311/http://www.isg.rhul.ac.uk/tls/TLStiming.pdf white paper]. The attack is shown to only work on LAN and is hindered by noise on the network (unwanted traffic). Timing the operations done for decryption, Lucky 13 is able to restore plaintext from an encrypted message.		Lucky 13 is a timing attack on TLS/DTLS protocol discovered in 2012 by Nadhem AlFardan and [http://web.archive.org/web/20220531081741/https://www.isg.rhul.ac.uk/~kp/ Kenny Paterson]. In 2013, they published their findings and released their [http://web.archive.org/web/20190414143311/http://www.isg.rhul.ac.uk/tls/TLStiming.pdf white paper]. The attack is shown to only work on LAN and is hindered by noise on the network (unwanted traffic). Timing the operations done for decryption, Lucky 13 is able to restore plaintext from an encrypted message.

	== Basics ==		== Basics ==

NKirnbauer: expired links changed with links from wayback machine

2024-10-22T14:36:59Z

expired links changed with links from wayback machine

← Older revision		Revision as of 14:36, 22 October 2024
Line 1:		Line 1:

	Lucky 13 is a timing attack on TLS/DTLS [https://wiki.elvis.science/index.php/protocol protocol] discovered in 2012 by Nadhem AlFardan and [http://www.isg.rhul.ac.uk/~~%7Ekp~~ Kenny Paterson]. In 2013, they published their findings and released their [http://www.isg.rhul.ac.uk/tls/TLStiming.pdf white paper]. The attack is shown to only work on LAN and is hindered by noise on the network (unwanted traffic). Timing the operations done for decryption, Lucky 13 is able to restore plaintext from an encrypted message.		Lucky 13 is a timing attack on TLS/DTLS [https://wiki.elvis.science/index.php/protocol protocol] discovered in 2012 by Nadhem AlFardan and [http://web.archive.org/web/20220531081741/https://www.isg.rhul.ac.uk/~kp/ Kenny Paterson]. In 2013, they published their findings and released their [http://web.archive.org/web/20190414143311/http://www.isg.rhul.ac.uk/tls/TLStiming.pdf white paper]. The attack is shown to only work on LAN and is hindered by noise on the network (unwanted traffic). Timing the operations done for decryption, Lucky 13 is able to restore plaintext from an encrypted message.

	== Basics ==		== Basics ==
Line 166:		Line 166:
	== References ==		== References ==
	<references />		<references />
	* http://www.isg.rhul.ac.uk/tls/TLStiming.pdf		* http://web.archive.org/web/20190414143311/http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

	[[Category:Documentation]]		[[Category:Documentation]]

NKirnbauer: fixed math tag errors, added category

2024-10-16T09:51:32Z

fixed math tag errors, added category

← Older revision		Revision as of 09:51, 16 October 2024
Line 10:		Line 10:

	IV = Initialization Vector is a (pseudo)random sequence of characters added to an encryption key. The IV should be different for any two messages encrypted with the same cryptography key.		IV = Initialization Vector is a (pseudo)random sequence of characters added to an encryption key. The IV should be different for any two messages encrypted with the same cryptography key.
	First step is to divide the pain text into block size (size depends on underlying symmetric encryption algorithm). Plain text (<math>P_i</math>) and previous ciphertext (<math>\C_{~~i−1~~}</math>) are combined with an XOR operation. Then it gets encrypted with the key. ''Repeat''.		First step is to divide the pain text into block size (size depends on underlying symmetric encryption algorithm). Plain text (<math>P_i</math>) and previous ciphertext (<math>\C_{i-1}</math>) are combined with an XOR operation. Then it gets encrypted with the key. ''Repeat''.
	In the first step we do not have any ciphertext (<math>C_i</math>) so we use the IV (initialization vector) for this one.		In the first step we do not have any ciphertext (<math>C_i</math>) so we use the IV (initialization vector) for this one.
	<math>E</math> stands for the encryption process.		<math>E</math> stands for the encryption process.
Line 129:		Line 129:
	Case <math>M_1</math>: Plaintext with valid 1-byte padding pattern remains "0x00". Padding (single byte) is removed, and a long message remains (287 bytes). The message is interpreted as the same as previously, MAC and message. MAC verification fails as well. Then we compare how log it takes to calculate the MAC verification.		Case <math>M_1</math>: Plaintext with valid 1-byte padding pattern remains "0x00". Padding (single byte) is removed, and a long message remains (287 bytes). The message is interpreted as the same as previously, MAC and message. MAC verification fails as well. Then we compare how log it takes to calculate the MAC verification.

	The longer message $M_1$ takes more time to calculate because a header and 255 bytes are passed through the MAC algorithm (compared to <math>M_0</math>'s 16 bytes). This allows us to distinguish between the two Messages <math>M_1</math> and <math>M_0</math>.		The longer message <math>M_1</math> takes more time to calculate because a header and 255 bytes are passed through the MAC algorithm (compared to <math>M_0</math>'s 16 bytes). This allows us to distinguish between the two Messages <math>M_1</math> and <math>M_0</math>.


Line 165:		Line 165:

	== References ==		== References ==
	~~{{reflist}}~~		<references />
	* http://www.isg.rhul.ac.uk/tls/TLStiming.pdf		* http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

			[[Category:Documentation]]

JSchwinger at 19:49, 16 January 2022

2022-01-16T19:49:19Z

← Older revision		Revision as of 19:49, 16 January 2022
Line 1:		Line 1:

	Lucky 13 is a timing attack on TLS/DTLS discovered in 2012 by Nadhem AlFardan and [http://www.isg.rhul.ac.uk/%7Ekp Kenny Paterson]. In 2013 they published their findings and released their [http://www.isg.rhul.ac.uk/tls/TLStiming.pdf ~~whitepaper~~]. The attack is shown to only work on LAN and is hindered by noise on the network (unwanted traffic).		Lucky 13 is a timing attack on TLS/DTLS [https://wiki.elvis.science/index.php/protocol protocol] discovered in 2012 by Nadhem AlFardan and [http://www.isg.rhul.ac.uk/%7Ekp Kenny Paterson]. In 2013, they published their findings and released their [http://www.isg.rhul.ac.uk/tls/TLStiming.pdf white paper]. The attack is shown to only work on LAN and is hindered by noise on the network (unwanted traffic). Timing the operations done for decryption, Lucky 13 is able to restore plaintext from an encrypted message.

	~~To understand~~ the ~~attack~~, ~~first explanation of a few concepts~~ is ~~needed~~.

	== Basics ==		== Basics ==
Line 167:		Line 165:

	== References ==		== References ==
			{{reflist}}
	* http://www.isg.rhul.ac.uk/tls/TLStiming.pdf		* http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

JSchwinger at 19:38, 16 January 2022

2022-01-16T19:38:17Z

← Older revision		Revision as of 19:38, 16 January 2022
Line 164:		Line 164:
	* Introduce random delays during decryption.		* Introduce random delays during decryption.
	* Switch to TLS 1.2 with support for AES-GCM and AES-CCM.		* Switch to TLS 1.2 with support for AES-GCM and AES-CCM.


			== References ==

			* http://www.isg.rhul.ac.uk/tls/TLStiming.pdf