You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2006/05/02 18:23:48 UTC
[jira] Commented: (DERBY-1156) allow the encrypting of an existing
unencrypted db and allow the re-encrypting of an existing encrypted db
[ http://issues.apache.org/jira/browse/DERBY-1156?page=comments#action_12377425 ]
Daniel John Debrunner commented on DERBY-1156:
----------------------------------------------
Comments on the functional part of the spec:
Encrypting an existing un-encrypted database:
- I assume the other encryption properties can be set at this time, such as encrpytionAlgorithm - would be good to state that.
- jdbc:derby:salesdb;dataEncryption=true;bootPassword=1234xyz - Does this example work? I thought the boot password had
to be at least eight characters?
Encrypting with a new password or a new encryption key:
- Just want to ensure the terminology is clear here,
"Database will be encrypted with new password/key if it is booted with following new URL attributes:"
The database is always encrypted with a new encryption key, and if newBootPassword is used then that key
is protected with a new boot password.
"... all the data in the database will be encrypted using this password ..."
.. all the data in the database will be encrypted with a newly generated key ...
In this mode can the encryption algorithm be changed?
> allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1156
> URL: http://issues.apache.org/jira/browse/DERBY-1156
> Project: Derby
> Type: Improvement
> Components: Store
> Versions: 10.1.2.3
> Reporter: Mike Matrigali
> Assignee: Suresh Thalamati
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: encryptspec.html
>
> encrypted database to be re-encrypted with a new password.
> Here are some ideas for an initial implementation.
> The easiest way to do this is to make sure we have exclusive access to the
> data and that no log is required in the new copy of the db. I want to avoid
> the log as it also is encrypted. Here is my VERY high level plan:
> 1) Force exclusive access by putting all the work in the low level store,
> offline boot method. We will do redo recovery as usual, but at the end
> there will be an entry point to do the copy/encrypt operation.
> copy/encrypt process:
> 0) The request to encrypt/re-encrypt the db will be handled with a new set
> of url flags passed into store at boot time. The new flags will provide
> the same inputs as the current encrypt flags. So at high level the
> request will be "connect db old_encrypt_url_flags; new_encrypt_url_flags".
> TODO - provide exact new flag syntax.
> 1) Open a transaction do all logged work to do the encryption. All logging
> will be done with existing encryption.
> 2) Copy and encrypt every db file in the database. The target files will
> be in the data directory. There will be a new suffix to track the new
> files, similar to the current process used for handling drop table in
> a transaction consistent manner without logging the entire table to the log.
> Entire encrypted destination file is guaranteed synced to disk before
> transaction commits. I don't think this part needs to be logged.
> Files will be read from the cache using existing mechanism and written
> directly into new encrypted files (new encrypted data does not end up in
> the cache).
> 3) Switch encrypted files for old files. Do this under a new log operation
> so the process can be correctly rolled back if the encrypt db operation
> transaction fails. Rollback will do file at a time switches, no reading
> of encrypted data is necessary.
> 4) log a "change encryption of db" log record, but do not update
> system.properties with the change.
> 5) commit transaction.
> 6) update system.properties and sync changes.
> 7) TODO - need someway to handle crash between steps 5 and 6.
> 6) checkpoint all data, at this point guaranteed that there is no outstanding
> transaction, so after checkpoint is done there is no need for the log.
> ISSUES:
> o there probably should be something that catches a request to encrypt to
> whatever db was already encrypted with.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira