If you want to store data in a way that the person holding the data cannot read it, then
- You need to encrypt the data client-side. Encrypting server-side opens the possibility that someone (say, the operator of the service) can record the data while it's in transit.
- The encryption needs to be done using client-selected keys. If anyone else provides the keys, they can record them.
- The client needs to be storable offline (so the service operator can't tamper with it after the fact) and should have source code available (so the user can audit it to ensure it does what it's supposed to).
To prevent the service operator from associating data with an account, the "store" operation is not "associate a new record with this account", but "store a record tagged with this hash", where the hash in question is provided by the client (say, a salted hash of their password, where the salt is the index number of the desired record). Conversely, the retrieval operation is not "select records associated with this account", but "select records tagged with this hash". Further, the "store" and "retrieve" operations cannot require the user to be logged in. There's probably a way for a user to prove they have an account without revealing which account it is, but I don't know how to do it.
Theoretically, any user can request any other user's records, though with a 256-bit hash, the odds of any random request returning a value are vanishingly rare (1 in 10^68, if you've got a billion records stored). Since an attacker doesn't have the decryption password, being able to retrieve someone else's record is of little value.