Dalla tua descrizione, presumo che tu (A) non abbia effettivamente bisogno di accedere ai dati degli utenti (B) in qualsiasi momento? Vale a dire. I dati di un negozio B, niente di più.
Se è così, tutta la tua idea suona male.
Qualcosa sulla normale crittografia asimmetrica prima:
- La chiave pubblica è usata per en crypt. La chiave pubblica, non la chiave privata. L'idea è che decifrare sia difficile. Non sarà difficile se ti serve la chiave pubblica.
- Non c'è qualcosa come una chiave pubblica / semi-privata. Uno dei due portachiavi può sempre calcolare anche l'altra chiave (ma non viceversa), cioè la chiave privata può essere utilizzata per calcolare la chiave pubblica.
- Non esiste uno schema di crittografia (singolo) asimmetrico in cui la decifrazione richiede entrambe le chiavi. Potresti usare due coppie di kay, es. 4 chiavi, per fare qualcosa del genere, ma non una singola coppia pubblica / privata.
Detto questo, il prossimo problema è la tua definizione di "archiviazione senza accesso". Se A vuole archiviare dati senza avere accesso, perché B dovrebbe inviare i dati semplici ad A? Perché è esattamente quello che stai proponendo: B invia i dati ad A in modo che A possa crittografarli. Prima di crittografare, A ha accesso in abbondanza. Stessa storia dopo quando viene decifrato di nuovo sul lato A prima che i dati vengano inviati a B.
Terzo, A dà a B una chiave e in seguito B rimanda la chiave ad A? Come sei sicuro che A non manterrà la chiave per avere accesso in ogni momento? E perché le chiavi vengono mandate in giro?
Cosa potresti fare (ed è molto più semplice): A memorizza i dati, come hai detto tu, e niente di più . Non inventare strategie di crittografia non biologiche coinvolgenti entrambe le parti. Se B vuole che i dati siano privati, B può crittografare i dati da solo, con le proprie chiavi e i propri metodi, prima inviandoli ad A. A non otterrà mai alcuna chiave.
E se hai questo, dovresti pensare anche a integrità + autenticità.