The best practice to manage the private / secret keys in memory is to use a memory physically out of reach of attackers, such as a HSM, Smart Card, Trusted Platform Module, or Secure Element.
Problem is, that's hardware, and on modern machines (servers, cloud, PCs, mobile), trusted hardware is not easily usable (though often present; in particular I see some renewed interest for TPM 2.0 in server/cloud).
Software-only options are a compromise. A reasonable one it to
- Trust the hardware + OS to keep at least memory content of a process private, and keep private / secret keys is a separate process doing the crypto, exchanging messages with the process using the crypto.
- AND stick to algorithms that have inherent protection against side-channel / cross-process leaks, because attacks on this front are aplenty. Libsodium is a good choice from this standpoint.
The combination at least makes a leak of a private / secret key unlikely to result from vulnerabilities in the process using the crypto (due to practically inevitable bugs in the unmanageably complex software stack involved in a typical application). A drawback is that access to the process doing the crypto must be managed securely (e.g. thru access rights enforced by the OS), which adds complexity.
One way to see so-called "enclaves" is as a standardized implementation of that design principle.
My opinion on the subject of multiplying the secret versus using pointers to a centralized area is that it is secondary from a security standpoint, compared to process isolation. I tend to prefer pointers, not so much because it is slightly more efficient, but because it saves from the hassle of having to zero copies no longer in use in order to follow guidelines requiring that. I regard such zeroing as technically non-essential (again, compared to process isolation); but like using e > 216 in RSA, it's something to bow at.