temo si stia mescolando due concetti qui, l'autenticazione/autorizzazione e riservatezza, cercando di coprire entrambi gli aspetti in un'unica fase, e ciò non funzionerà. Non si dovrebbe mai crittografare "dati reali" con algoritmi asimmetrici. a) sono troppo lenti per questo, b) ci sono problemi delicati che, se non eseguiti correttamente, indeboliranno gravemente la sicurezza della soluzione.
Una buona regola generale è che l'unica cosa che si dovrebbe finire la cifratura con privati asimmetrici chiavi è simmetriche chiavi usate da un algoritmo molto più veloce simmetrica. Ma in quasi tutti i casi non dovresti nemmeno farlo, perché nel 90% dei casi quello che vuoi veramente è TLS (SSL) in questi casi - ho provato a spiegare perché qualche tempo fa lo here.
Nel tuo caso, suppongo che i requisiti sono:
la riservatezza dei dati che devono essere memorizzati nel database: il pubblico in generale non dovrebbe essere in grado di leggere (o anche accedervi)
un selezionato alcuni (probabilmente una sola persona) dovrebbe essere in grado di accedere e leggere i dati
Il primo obiettivo è generalmente ottenuto utilizzando 012.. Il secondo obiettivo è, benché correlato, realizzato con mezzi abbastanza diversi. Si desidera che l'utente acceda al file da autenticare (cioè, stabilisce l'identità) e in aggiunta si desidera che siano autorizzati (ad es.verificare se l'identità stabilita ha il diritto di fare ciò che intendono). È qui che la crittografia asimmetrica può entrare nello stage, ma non necessariamente. Dal momento che la tua domanda è taggata con Rails presumo che stiamo parlando di un'applicazione Rails. In genere si dispone già di mezzi per autenticare e autorizzare gli utenti (molto probabilmente con il suddetto TLS), è possibile semplicemente riutilizzarli per stabilire una chiave simmetrica per la crittografia/decrittografia dei file effettivi. Password-based encryption si adatta a questo scopo, se si desidera evitare la crittografia asimmetrica. Le cose diventano ancora più complicate se si vuole anche garantire l'integrità dei dati già riservati, cioè si vuole dare una sorta di garanzia all'utente autenticato e autorizzato nel senso che ciò che finalmente accede non è stato alterato in alcun modo nel frattempo.
Sviluppare una soluzione per questo non sarà un compito banale e dipenderà in larga misura dalle vostre esigenze, quindi temo che non ci sia una "via d'oro" adatta a tutti. Vorrei suggerire di fare qualche ricerca, ottenere un'immagine più chiara di ciò che stai cercando di ottenere e di come, quindi cercare di ottenere ulteriori consigli su argomenti che ti senti ancora incerto/a disagio.
In realtà non sono Rubyist, ma quelle sono batterie piuttosto buone. Mi chiedo quanto sia difficile l'equivalente in Python ... – brice
Voglio solo aggiungere che i file dovrebbero essere ecnrypted con, ad esempio, AES-256, ma la sua chiave dovrebbe essere inviata con rsa. – tiktak
Mi dispiace, ma questo è davvero un cattivo consiglio. L'OP parla della crittografia/decrittografia dei file e non si dovrebbe mai usare RSA per questo. – emboss