[QUOTE=jvang;496115]How would you work out these problems/proofs?[/QUOTE]
We have the following sum, where a,b,c,x,y and z represent unknown decimal digits,
and we are adding the 3 numbers together:

[CODE]
xyz000
xyz
xyz
______
ab007c
[/CODE]Look at the tens column: 7 is odd but 0+y+y is even so there must have been a carry out of the units column.
Thus we know that z≥5 and either y=3 or y=8.
Look at the hundreds column: 0 is even and so is 0+x+x so there was no carry out of the tens olumn.
Hence yz<50 (where yz is the number with digits y then z) and either x=0 or x=5.
Now look at the thousands column: if xyz≥500 then z=9 and otherwise z=0.

Combining what we know, we see that z=9, y=3 and x=5.
It follows that the original 3-digit number was 539.
(Crosspost with Jacob)

It is overcomplicated. Obviously we are searching 0<x<1000.

1002*x=1000*x+2*x, and here there is no carry or carry=1 in the hundred's for 2*x.

If there is no carry then:
2*x=7c and
x=ab0, from the first equation x is in [35,40), but it has no integer divisible by 10.

If there is a carry, then
2*x=107c and
x+1=ab0, from the first one x is in [535,540), from the second equation the last digit of x is 9.
Hence x=539.

[QUOTE=jvang;496035] the first microprocessor (released in the early 1970s by IBM)[/QUOTE]

Intel, not IBM

[QUOTE=jvang;495978]After looking up New Math I'm now wondering[/QUOTE]

I lived through New Math in the 7th and 8th grades. Our teachers were taking training courses and were only two or three chapters ahead of the students. The teachers were excited and interested in the stuff, and their enthusiasm carried over to make the classes interesting - so the students learned more than with traditional methods. Apparently after a few years the teachers again became bored and apathetic. When taught by bored, unmotivated teachers, New Math was inferior to Old Math.

That was long ago. I still remember learning base seven arithmetic - I guess it gave me the framework to understand binary, octal and hexadecimal plus the carry process in FFT multiplication And I remember having great difficulty finding the simple explanation for why a chess board covered with dominoes could not leave diagonal corners uncovered.

[QUOTE=wblipp;496137]Intel, not IBM[/QUOTE]

Whoops! I get those mixed up a lot. It's the same problem I have with my mixing up of Denver and Detroit, or Dubai and Delhi :ermm:

I can make sense of Jacob's and Nick's explanations, but not of Gerbicz's. I'm not really sure what is confusing, but each point doesn't seem to follow the others...

As for Haskell, I finished up my first level 4 kata today (and surpassed 500 honor!:max:); this one was [URL="https://www.codewars.com/kata/snail/"]Snail[/URL]. While figuring out how to work the problem, I came across [C]transpose[/C], which made everything much easier.

[CODE]module Snail where
import Data.List
snail :: [[Int]] -> [Int]
snail [] = []
snail (x:xs) = x ++ (snail (reverse (transpose xs)))[/CODE]

I suppose [C](xs:xss)[/C] would be more logically sound, as in the top solutions. This kata was either more intuitive than usual for me or not as difficult as a level 4 kata should be. I've looked at a lot of other ones, which seem much more scary :unsure:

I've been reading up on basic cryptography, mainly cryptographic hash functions and encryption. I think I understand how hashes are produced, the properties of ideal hash functions, how salts affect their outputs. Here’s a couple of things that I’ve learned;

From Wikipedia:
[QUOTE]The ideal cryptographic hash function has five main properties:[LIST][*]it is deterministic so the same message always results in the same hash[*]it is quick to compute the hash value for any given message[*]it is infeasible to generate a message from its hash value except by trying all possible messages[*]a small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value[*]it is infeasible to find two different messages with the same hash value[/LIST][/QUOTE]

There are also three properties pertaining to security that the ideal cryptographic hash function has:

Preimage resistance - it should be difficult to find a message given its hash. A good analogy I came across was that the hash of a message is like the fingerprint of a person; unique, and able to be used to identify the person, but you can't find much from being given nothing but the fingerprint.

Second preimage resistance - it should be difficult to find two distinct message that have the same hash. In the fingerprint analogy, this is like multiple people having the same fingerprint; it would be hard to distinguish between their identities given all of their fingerprints.

Collision resistance - basically the same as second preimage resistance, but does not imply the first one. This is also referred to as strong collision resistance, and second preimage resistance is referred to as weak collision resistance. Strong collision resistance generally requires a hash value at least twice as long as that required for preimage-resistance, otherwise collisions may be found by a birthday attack (exploiting the cryptological equivalent of the [URL="http://en.wikipedia.org/wiki/Birthday_problem"]birthday problem/paradox[/URL]).

Weak collision resistance, or second preimage resistance, prevents an attacker from crafting a document with the same hash as a document the attacker cannot control. Strong collision resistance prevents an attacker from creating two distinct messages with the same hash. Strong includes weak, but not the other way around (and not including preimage resistance).

The idea behind a salt is that you append a random string to a message before hashing it. This produces an even more difficult to reproduce hash, which defends against dictionary attacks or rainbow table attacks, which compare hashes to a pre-computed table of hashed messages to see which ones match.

I have a few questions:

If I understand correctly, passwords on UNIX systems are hashed with a random salt, then stored in a file. If the salt is random, how do you compare an input to the hash in the file to see if they are the same?

How does public key encryption work? I understand how encryption with a predetermined private key works, but I haven’t found a good resource on how public key encryption works. How is information passed along if it's unfeasible to recreate the message from the hash? (Then it seems like the only use for hashes is as a checksum or something similar, or maybe this is not really related to said encryption)

I think it’s amazing that changing a single character in a string produces an entirely different hash. How does a one-way function work, and would a simple example even resemble a mathematical function?

[QUOTE=jvang;496212]If I understand correctly, passwords on UNIX systems are hashed with a random salt, then stored in a file. If the salt is random, how do you compare an input to the hash in the file to see if they are the same?[/QUOTE]

You understand correctly. The Salt is stored in the /etc/shadow file, along with the Hash, which can only be read by the "Super User". It is used during the hashing function to confirm a password given is correct.

Without meaning to blow sunshine, I do find it somewhat encouraging that a young person is so willing to learn. Somewhat a rarity in this day-and-age. :tu:

[QUOTE=jvang;496212]
How does public key encryption work? I understand how encryption with a predetermined private key works, but I haven’t found a good resource on how public key encryption works. [/QUOTE]
We have a short description of RSA in the Number Theory Discussion subforum here:
[URL]https://www.mersenneforum.org/showthread.php?t=21756[/URL]
[QUOTE=jvang;496212]
How is information passed along if it's unfeasible to recreate the message from the hash? (Then it seems like the only use for hashes is as a checksum or something similar, or maybe this is not really related to said encryption)[/QUOTE]
You're right that you cannot decrypt a hash, but they are still useful for a lot more than just checksums. Here's an example.
The protocol for tossing a coin is widely known and accepted, e.g. at the start of a sports match.
But how would you do it with someone via this forum?
Suppose I'm tossing a coin and you're calling heads or tails.
If you post your call first and then I post how the coin fell, then I can cheat.
But if I post how the coin fell first and then you post what you called, then you can cheat.

So instead I think of a random number xxxxxxxxx and post the hash of HEADSxxxxxxxxx or TAILSxxxxxxxxx.
You then post what you are calling, heads or tails.
Then I post what I had hashed.

[QUOTE=jvang;496212]How does public key encryption work? I understand how encryption with a predetermined private key works, but I haven’t found a good resource on how public key encryption works. How is information passed along if it's unfeasible to recreate the message from the hash? (Then it seems like the only use for hashes is as a checksum or something similar, or maybe this is not really related to said encryption)

I think it’s amazing that changing a single character in a string produces an entirely different hash. How does a one-way function work, and would a simple example even resemble a mathematical function?[/QUOTE]The answer to your second question follows directly from a simple example of public key encryption --- Diffie-Helman key exchange.

DH relies for its security on the difficulty of solving the equation [I]y = g[sup]x[/sup][/I] mod [I]p[/I] for x, given publicly visible integer values of [I]g, y[/I] and [I]p[/I]. Here [I]p[/I] is a large prime number. Note that if you know [I]x[/I] it is easy to compute [I]y[/I].

So let's exchange a secret message. We agree ahead of time, by a forum posting perhaps, on values for [I]g[/I] and [I]p[/I]. I choose a value [I]x_xilman[/I] using a strong random number generator and keep that value secret. In a subsequent posting I give [I]y_xilman = g[SUP]x_xilman[/SUP][/I] mod [I]p[/I] for you to read. In the meantime you do exactly the same with your favourite RNG to choose [I]x_jvang[/I] which you keep secret and then post [I]y_jvang[/I]. Now everyone reading the forum knows everything we've posted in public. I don't know your secret, neither do you know mine, everyone else doesn't know either of them.

Here is the cute bit. I raise your [I]y_jvang [/I]to the power of my [I]x_xilman[/I] mod [I]p[/I] and you do the same with the [I]jvang[/I] and [I]xilman[/I] roles exchanged. Think about it and you will see that we now have exactly the same value: [I]g[SUP]x_xilman*x_jvang[/SUP][/I] mod [I]p[/I] (let's call it [I]K[/I] for brevity) but no-one else does unless they can solve a very difficult discrete logarithm problem.

Right, we now have a shared secret [I]K[/I]. We agree on a symmetric encryption algoritm, AES perhaps, and use [i]K[/i] as the key. Once more our messages can be exchanged in a public forum as long as we trust the security of AES.

BTW, the answer to your second question can now be found in my second paragraph above.

[QUOTE=chalsall;496213]Without meaning to blow sunshine, I do find it somewhat encouraging that a young person is so willing to learn. Somewhat a rarity in this day-and-age. :tu:[/QUOTE]

You'd be surprised at how many young people enjoy learning. Not all millennials are lazy deadbeat neckbeards dwelling in their parents' basements! :razz:

I appreciate the responses, but I'm afraid that this cryptography stuff is much too complicated for me to comprehend (perhaps that's why only smart people are doing it!). I understood very little of what Nick linked to, and I got lost somewhere in Paul's 3rd or 4th paragraph :unsure:

My dad has suggested that, each day, I post about something I've learned and present it in a learnable format, e.g. notes. This is kinda what I've been doing with Linux and Haskell, but if I come across anything cool in other fields I'll cover that. Today is file systems:

A file system consists of two or three layers. Sometimes the layers are explicitly separated, and sometimes their functions are combined. The first layer is the logical file system, which is responsible for interaction with the user application. It passes requested operations (like reading and writing) to the layer below it for processing.

The second optional layer is the virtual file system. This is supposed to allow "applications to access different types of concrete file systems in a uniform way" (as per the Wikipedia article). I'm guessing that this is vaguely similar to virtual memory, and ends up acting as a transfer mechanism between the third layer and something important?

The third layer is the physical file system, which is concerned with the physical operation of the storage device. It processes physical blocks being read or written. It also handles buffering, memory management, and the physical placement of blocks in specific locations on the storage medium.

[QUOTE=jvang;496265]I'm afraid that this cryptography stuff is much too complicated for me to comprehend (perhaps that's why only smart people are doing it!). I understood very little of what Nick linked to, and I got lost somewhere in Paul's 3rd or 4th paragraph :unsure:[/QUOTE]

I think I'll try reading the explanations tomorrow and see if it makes any more sense. Not sure what isn't clicking :jvang:

[QUOTE=jvang;496279]I think I'll try reading the explanations tomorrow and see if it makes any more sense. Not sure what isn't clicking :jvang:[/QUOTE]Try writing down the equations and mathematical manipulations as you read through the explanations. Insert the "simple" intermediate steps which I omitted for brevity.

The first advice helps fix the notations and processes in your memory. The second ensures that you understand what is going on rather than just taking it for granted that you do. These techniques, of course, apply equally well to most mathematical explanations. Professional mathematicians use them all the time to understand papers written by others.