Do I need to use cipher_migrate when updating from 3.0.1 to 3.5.4

coconet · October 5, 2016, 9:41am

Hi everyone,

while updating the SQLCipher libs we encountered a problem. We get a SQLiteException: file is encrypted or is not a database after updating from 3.0.1 to 3.5.4. We are still investigating what is causing the problem. The provided password is identical to the one before the version change. Has the database encryption changed in the meantime? We do not use cipher_migrate because we upgrade within a major version. Is this assumption right?

Regards,
Mateusz

sjlombardo · October 5, 2016, 1:19pm

Hello @coconet - your assumption is correct, it should not be necessary to run cipher_migrate to upgrade within the same major version. This assumes that you are using the default settings, i.e. that you haven’t changed things like the KDF iterations, HMAC, etc. Are you able to reproduce the same behavior in a standalone application?

coconet · October 6, 2016, 1:34pm

Hi guys,

I found the problem. The fix for
github.com/sqlcipher/android-database-sqlcipher/issues/247
has a flaw.

github.com

sqlcipher/android-database-sqlcipher/blob/master/src/net/sqlcipher/database/SQLiteDatabase.java#L2404


      if (path == null) {
          throw new IllegalArgumentException("path should not be null");
      }


      mFlags = flags;
      mPath = path;


      mSlowQueryThreshold = -1;//SystemProperties.getInt(LOG_SLOW_QUERIES_PROPERTY, -1);
      mStackTrace = new DatabaseObjectNotClosedException().fillInStackTrace();
      mFactory = factory;
      mPrograms = new WeakHashMap<SQLiteClosable,Object>();


      mErrorHandler = errorHandler;
  }


private void openDatabaseInternal(final char[] password, SQLiteDatabaseHook hook) {
  boolean shouldCloseConnection = true;
  final byte[] keyMaterial = getBytes(password);
  dbopen(mPath, mFlags);
  try {

you compare the unicode representation of zero with the ascii representation of zero. so (48 == 0) is false. I need to refresh my encoding knowledge but this seems to be the reason for our problem.

Maybe rename the method to containsZero. containsNull sounds odd .

developernotes · October 6, 2016, 2:24pm

Hi @coconet

The default value of a char is the null character according to the Java spec here. Since we are comparing primitive types, we use ==. There is a corresponding test within the test suite that verifies the behavior (i.e., here). Do you have a different scenario?

sjlombardo · October 11, 2016, 2:04pm

@coconet - can you please provide a standalone code sample that demonstrates the problem you are seeing?

coconet · October 20, 2016, 4:01pm

Hi Stephen,

looks like I confused the zero-byte value with the zero value. So my
previous statement is not relevant and not an issue.

Anyway, our android app uses version 3.0.1 and after migrating to
version 3.5.4 the key does not unlock the database.
What I have done so far:
checked the passwords being entered in 3.0.1 and 3.5.4 -> both are the same.
checked the passwords until they enter the native methods -> both are
the same.
checked the bytes after

github.com

sqlcipher/android-database-sqlcipher/blob/master/src/net/sqlcipher/database/SQLiteDatabase.java#L2835


    }
    c.close();
    return attachedDbs;
}


private byte[] getBytes(char[] data) {
  if(data == null || data.length == 0) return null;
  CharBuffer charBuffer = CharBuffer.wrap(data);
  ByteBuffer byteBuffer = Charset.forName(KEY_ENCODING).encode(charBuffer);
  byte[] result =  new byte[byteBuffer.limit()];
  byteBuffer.get(result);
  return result;
}


/**
 * Sets the root directory to search for the ICU data file
 */
public static native void setICURoot(String path);


/**
 * Native call to open the database.

in 3.5.4 since this is the only real difference between the versions ->
they are the same as before.
I downloaded a working database from the android emulator and tried to
open it with sqlcipher 3.0.1 and 3.5.4. I failed with both attempts.
I rekeyed the database in our app to have a shorter key and tried to
open this database by hand. I failed again. the rekey has worked because
I can’t open the database with the old key.
I created a new database with a short key in our app and tried to open
the database by hand. I failed.

The only pragma commands we use in our code are key and rekey so I don’t
think we changed any default settings.

We patched in ormlite in between our app and sqlcipher. I see no problem
with this but maybe I am missing something.

Do you have any idea why I can’t open the database by hand? Can you give
me a direction what I should look into?

Can you have a look at the attached database? It contains only demo data.

Regards,
Mateusz

sjlombardo · October 20, 2016, 9:26pm

Hello @coconet

Are you sure you were using 3.0.1? What is the version reported by running “PRAGMA cipher_version;”?

Can you send me the database via a private message. It was not posted to this forum.

coconet · October 24, 2016, 11:28am

Hi Stephen,

turns out the app is using version 2.2 . Our documentation was wrong in
that point and I didn’t double check it … so much confusion when the
premise is wrong. Thanks for the hint.

Regards,
Mateusz

Topic		Replies	Views
How to properly use SQLCipher 4.5.0 on Android? SQLCipher	2	916	February 4, 2022
Upgrading Sqlcipher for Android from 3 to 4 Issues	6	4249	October 7, 2020
Migrating from SQLCipher 3.5.1 to 4.1.3 in Android Issues	12	4338	April 5, 2024
Migrate to 4.0.1. Same Password. File is not a Database for some users Issues	1	650	May 29, 2019
Migrating Android Application from SQLCipher 3 to 4	5	2002	October 1, 2019

Do I need to use cipher_migrate when updating from 3.0.1 to 3.5.4

Related Topics