Non descrivi il modello di attacco (cioè che tipo di cose un attaccante potrebbe voler ottenere) quindi devo fare qualche congettura qui ...
Una prima cosa da notare è che si sta codificando il "NomeSito", che si invia anche in testo non crittografato, quindi si deve presumere che ogni utente malintenzionato che osserva un messaggio in transito conosce "NomeSito". Inoltre, si cripta l'ora corrente, che è un dato pubblico (anche l'attaccante ha un orologio). La crittografia ha lo scopo di trasformare alcuni dati in un modo che mantenga le informazioni riservate, ma qui l'input per la funzione di crittografia è solo dati pubblici. Quindi stai usando un sistema di crittografia per qualcosa di diverso da quello per cui è stato progettato, e questa è una preoccupazione.
Come lo descrivi, ciò che sembri essere dopo è un modo per autenticare un messaggio temporizzato: desideri che la macchina B si assicuri che qualsiasi software venga eseguito sulla macchina. A produce deliberatamente un dato blob, che include la data e l'ora di produzione . Ciò richiede un codice di autenticazione dei messaggi , non la crittografia. Il solito MAC è HMAC che usa una funzione di hash sottostante (in caso di dubbio, scegli SHA-256); con PHP, vedi la funzione hash_hmac() . È possibile creare un MAC da un sistema di crittografia, ma è alquanto complicato e non vi è alcun motivo a priori per ritenere che mcrypt_encrypt() faccia qualcosa che è un buon MAC; Non che io sappia come romperlo, ma è meglio usare uno strumento che è stato specificamente progettato e studiato per essere un buon MAC, e questo è HMAC. Quindi vuoi che il messaggio di A contenga il NomeSito, il tempo di produzione del messaggio e un MAC calcolato su NomeSito e il tempo di produzione del messaggio, con $key come chiave.
Naturalmente, nulla impedisce a un utente malintenzionato di riprodurre un messaggio esistente, il che potrebbe o meno essere un problema con te, a seconda del computer B quando riceve una "richiesta valida". Come nota a margine, affidarsi al tempo corrente ha alcuni problemi pratici, perché ci sono molti utenti che sono abbastanza contenti di un orologio di sistema spento da alcuni anni (lavoro nel campo delle firme digitali e I certificati X.509, che hanno date di validità e un orologio di sistema non impostato sono il motivo numero 1 di errore).