Suppongo qui che key sia qualcosa di statico a livello di sistema, e non qualcosa che sceglie un singolo utente - se è così, è molto strano che sia letto come UTF-8 piuttosto che Base64 perché UTF-8 sarà un meccanismo di archiviazione inefficiente per la chiave in quanto non utilizzerà lo spazio chiavi completo. Lo metterei all'ingenuità dello sviluppatore piuttosto che a qualcosa di fuori ragione.
Questo metodo avrebbe più senso se fosse per una chiave scelta dall'utente, in quanto potrebbero aver inserito caratteri unicode come chiave, e quindi se è memorizzato e letto come UTF-8 può quindi essere messo in una chiave- funzione di stretching come PBKDF2. Qui l'obiettivo non è una memorizzazione efficiente, sarebbe semplicemente fare in modo che una chiave scelta dall'utente abbia abbastanza entropia per essere utile.
won't it mean that this key is more predictable that it should be?
Quando il tasto entra nella funzione HMAC, viene cancellato insieme al messaggio. Il fatto che provenga da una stringa UTF-8 non dovrebbe rendere più prevedibili gli HMAC risultanti, né dovrebbe rendere più semplice la forzatura della chiave. Finché la stringa originale ha abbastanza entropia all'inizio, non importa quale formato è stata convertita per la memorizzazione.
Can it still be secure enough provided the proper generation of this
key, and how should it be generated in this case?
Da questa risposta , sarebbe raccomandato un valore casuale a 128 bit generato tramite un generatore di numeri pseudo casuali crittograficamente sicuro per la chiave. Il CSPRNG genererebbe una sequenza di byte, quindi potrebbe essere Base64'd e quindi memorizzato come UTF-8, anche se lo spazio delle chiavi non viene mai riempito completamente. Sarebbe meglio se il passaggio UTF-8 potesse essere completamente rimosso, anche perché aggiunge complessità non necessaria.