1553: Public Key

2015-07-20T12:33:43Z

Egolub: /* Explanation */ corrected how signing works

{{comic
| number = 1553
| date = July 20, 2015
| title = Public Key
| image = public_key.png
| titletext = I guess I should be signing stuff, but I've never been sure what to sign. Maybe if I post my private key, I can crowdsource my decisions about what to sign.
}}

==Explanation==

In [https://en.wikipedia.org/wiki/Public-key_cryptography Public-key cryptography], two keys are generated for a user. The public key can be used to encrypt messages, but not decrypt them. The private key is necessary for decryption.

The public key is designed to be shared. People share their public keys so anybody can send them an encrypted message. Cueball has been following this rule. However, nobody wants to send him encrypted messages. Cueball contemplates sharing his private key, which would allow anyone to decrypt his messages. This change would defeat the whole purpose of encryption, and it would not solve Cueball's problem.

The title text refers to another feature of Public-key cryptography: messages can be "signed" with the private key. These messages can be read by anyone, but readers with the public key can verify that the owner of the private key wrote (or at least signed) the message. If Cueball published his private key, anybody could sign anything as him. Once again, this would defeat the purpose of encryption.

==Transcript==
{{incomplete transcript}}

[In the first panel, Cueball is sitting in a chair and is using a laptop.]

Cueball: I've been posting my public key for 15 years now, but no one has ever asked me for it or used it for anything as far as I can tell.

[Two panels with Cueball thinking silently.]

Cueball: Maybe I should try posting my ''private'' key instead.

{{comic discussion}}

[[Category:Cryptography]]
[[Category:Comics featuring Cueball]]

1537: Types

2015-06-12T12:31:34Z

Egolub: /* Explanation */ explaining 2+2 in context of programming languages that allow literals to be changed

{{comic
| number = 1537
| date = June 12, 2015
| title = Types
| image = types.png
| titletext = colors.rgb("blue") yields "#0000FF". colors.rgb("yellowish blue") yields NaN. colors.sort() yields "rainbow"
}}

==Explanation==
{{incomplete|Initial draft.}}

This comic is a series of programming jokes about a ridiculous new programming language:

# <code>2 + "2"</code> uses the <code>+</code> operator on a number and a string. In a normal language, this would result either the number <code>4</code> (addition), or <code>"22"</code> (string concatenation); however, the new language converts the string to an integer, adds them to produce <code>4</code> and converts back to a string.
# <code>"2" + []</code> adds a string to an array (a list), this time. This first inexplicably converts the string to a number again, and then it literally adds the number to the list by appending it (this would make sense if it was <code>[] + 2</code>, but usually not the other way around). And then the result is converted to a string again.
# <code>(2/0)</code> divides <code>2</code> by <code>0</code> and quite reasonably results in <code>NaN</code> (not a number).
# <code>(2/0)</code> adds <code>2</code> to <code>NaN</code>. <code>2</code> is "added" to the string <code>"NaN"</code> (again, the number is converted to a string for apparently no reason), which produces <code>"NaP"</code>, as if <code>2</code> was added to <code>"N"</code> to produce <code>"P"</code> (as per alphabetical order).
# <code>""+""</code> looks like it is concatenating (adding) an empty string to another empty string, which should produce an empty string. However, the entire thing is treated as one string (with the start quote being the first one and the end quote being the very last one), which produces the egregious '<code>"+"</code>'.
# <code>[1,2,3]+2</code> seems to test whether it's sound to append <code>2</code> to the list <code>[1,2,3]</code>, and concludes that it doesn't fit the pattern, returning the boolean value <code>false</code>.
# <code>[1,2,3]+4</code> returns <code>true</code> for much the same reason.
# <code>2/(2-(3/2+1/2))</code> is a floating point joke. Floating point numbers are notoriously imprecise. With precise mathematics, <code>(3/2+1/2)</code> would be exactly 2, hence the entire thing would evaluate to <code>2/0</code> or <code>NaN</code> in Randall's new language. However, the result of <code>(3/2+1/2)</code> is "just slightly off," which makes the result "just slightly off" of <code>NaN</code> (which would be ridiculous in a real language). The ironic thing is that fractions with 2 in the denominator are ''not'' the kind of numbers that typically suffer from floating point impreciseness.
# <code>range(" ")</code> normally wouldn't make any sense. However, the new language appears to interpret it as ASCII, and in the ASCII table, character #32 is space, #33 is <code>!</code>, and #34 is <code>"</code>. So, instead of interpreting <code>" "</code> as a string, it seems to be interpreted as <code>34, 32, 34</code> (in ASCII), and then <code>range</code> appears to transform this into <code>34, 33, 32, 33, 34</code> (the "ranges" between the numbers), which, interpreted as ASCII, becomes <code>['"', '!', ' ', '!', '"']</code>.
# <code>+2</code> appears to be applying a unary <code>+</code> to the number <code>2</code>, which should just be <code>2</code>. However, the code is adding <code>2</code> to the line number <code>10</code> in this context.
# <code>2+2</code> would normally be <code>4</code>. However, the interpreter takes this instruction to mean to add the value 2 to the literal value of <code>2</code>, making it <code>4</code> and then reports that the work is "Done". This can be seen in the subsequent lines where all <code>2</code>s are replaced by <code>4</code>s. This could be a reference to languages like Fortran where literals were able to be assigned new values.
# <code>range(1,5)</code> would normally return <code>[1, 2, 3, 4, 5]</code>. However, since the value of <code>2</code> has been changed to <code>4</code>, it returns <code>[1, 4, 3, 4, 5]</code>, and this even affects the line number (which is 14 instead of 12).
# <code>floor(10.5)</code> should return <code>10</code> (the "floor" of a decimal number is that number rounded down). However, it instead returns... a picture of the number on a "floor."

==Transcript==
My new language is great, but it has a few quirks regarding type:
<pre>
[1]> 2+"2"
=> "4"
[2]> "2"+[]
=> "[2]"
[3]> (2/0)
=> NaN
[4]> (2/0)+2
=> NaP
[5]> ""+""
=> '"+"'
[6]> [1,2,3]+2
=> FALSE
[7]> [1,2,3]+4
=> TRUE
[8]> 2/(2-(3/2+1/2))
=> NaN.0000000000000013
[9]> range(" ")
=> ('"','!'," ","!",'"')
[10]> +2
=> 12
[11]> 2+2
=> DONE
[14]> RANGE(1,5)
=> (1,4,3,4,5)
[13]> FLOOR(10.5)
=> |
=> |
=> |
=> |
=> |___10.5___
</pre>

{{comic discussion}}

explain xkcd - User contributions [en]

1553: Public Key

1537: Types