I am currently working my way into hashing with SHA512.
To my knowledge, the result of such hashing is often passed around as a string in this format
$6$salt$hashed-secret
And now I am simply wondering: within this string, what is the true nature of "salt" and "hashed-secret" --- are they "real" strings (as shown here for example, as output of the crypt tool); or is there a "rule" that says that those strings should always be base64 encoded.
You need to distinguish between SHA512 (a general-purpose hash function) and sha512crypt (a password hashing function based on SHA512). A string starting with $6$ is the output from sha512crypt. It's possible you knew this already, but the wording of your question leaves open the possibility that you didn't.
The specification for sha512crypt is here. It doesn't say much about the construction of the salt, only this:
For the SHA-based methods the SALT string can be a simple string of which up to 16 characters are used.
At least one implementation (for python) says that the salt must be composed of alphanumerics, dot, and slash (the characters used in the original DES-based unix crypt). I think it would be wise to stick to those characters.
The hashed-secret is base64 encoded, not with the MIME base64 alphabet but with the unix crypt alphabet.
The encoding used is as follows:
111111111122222222223333333333444444444455555555556666 0123456789012345678901234567890123456789012345678901234567890123 ---------------------------------------------------------------- ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
often passed around as a string in this format
I think I get invited to different parties than you do.
This is the format used for storing passwords on Unix systems and processed by crypt. Its also used in some other systems (e.g. apache).
is there a "rule" that says that those strings should always be base64 encoded.
Crypt does not use base64 (or at least it never doesn't for older password formats) it uses radix-64 encoding. Both use 64 ascii characters to encode binary data - but they are not compatible.
AFAIK there is no standards documenting defining these records - only a convention.
That format is just a common representation of the underlying hash value. The hash itself is a binary value of a specified length (depending on the specific hashing algorithm used). In the case of SHA-512, it's 512 binary digits, or 64 bytes, or 128 hexadecimal characters, or an 88 character long base64 encoded string. They all correspond to the same underlying hash, just as "one", "un" and "eins" all correspond to 1.
Similarly, the salt is just a bunch of binary digits. You could represent it in any form you choose, as long as you represent it in the same way wherever you expect to be able to compare hash values. Base64 encoding just happens to be a fairly reasonable way of transferring arbitrary binary data around. In some cases, the bunch of binary digits happens to correspond to a string in some text encoding format, in which case you wouldn't need the encoding, technically, but you would need some way of detecting whether the string was intended as a string, or as a representation of underlying binary.
