[guardian-dev] porting GnuPG to Java vs improving the native Java APG

Stephen Lombardo sjlombardo at zetetic.net
Thu Nov 17 13:09:12 EST 2011


Hi All,

Without commenting on the merits or scope of managing keys for SQLCipher, I
did want to mention that SQLCipher does allow the use of raw key data. You
can pass in a raw key in the standard SQLite blob notation, x'hex', i.e.

PRAGMA key =
"x'98483C6EB40B6C31A448C22A66DED3B5E5E8D5119CAC8327B655C8B5C4836481'";


When called this way SQLCipher will bypass key derivation and use the key
data directly, provided the hex data contains the proper number of bytes to
match the algorithm's key size.

This feature was included to make SQLCipher suitable for use in the
following situations:

1. key data is stored in an external system (i.e. a keychain / escrow)
2. the key data is exchanged between parties via public key cryptography
3. the performance impact of PBKDF2 is a problem, e.g. if a database is
opened and closed very frequently
4. an application wishes to use its own key derivation scheme like bcrypt
or scrypt

Cheers,
Stephen

On Thu, Nov 17, 2011 at 12:45 PM, Hans-Christoph Steiner <hans at at.or.at>wrote:

>
> I think the SQLCipher API only allow for passphrases.  Some kind of key/pw
> storage utility would be very useful, but I don't see how passphrases could
> be stored in a GnuPG keyring.
>
> I'm currently thinking of this portion of the project as crypto identity
> management more than key management.  Yes, this means managing keys, but
> the focus is on keys related to identity rather than keys only for
> encrypted storage.
>
> .hc
>
> On Nov 16, 2011, at 9:27 PM, devrandom wrote:
>
> > You could store the AES key in a file, encrypted to the user's public
> > key.  The user would then just have to unlock their public key to
> decrypt.
> >
> > It sounds like you are going into the key management business, and
> > SQLCipher could be an additional key to manage.  Or actually more than
> > one if there are multiple SQLCipher based apps.
> >
> > On 11-11-16 06:07 PM, Hans-Christoph Steiner wrote:
> >>
> >> How would that work?  SQLCipher uses AES, so symmetric, shared secret
> encryption.
> >>
> >> .hc
> >>
> >> On Nov 16, 2011, at 9:03 PM, devrandom wrote:
> >>
> >>> I wonder if it makes sense for GnuPG to manage SQLCipher keys,
> system-wide.
> >>>
> >>> On 11-11-16 11:31 AM, Hans-Christoph Steiner wrote:
> >>>>
> >>>> I'm currently working on making GnuPG keys the backend for managing
> OTR keys, so that's my current use case.  But at the very least, I'll
> bundle this up in to a JNI/lib package, and hopefully also put an Android
> GUI on it.
> >>>>
> >>>> .hc
> >>>>
> >>>> On Nov 16, 2011, at 1:02 PM, Miron wrote:
> >>>>
> >>>>> These are good arguments for porting GnuPG.  What use cases are you
> >>>>> envisioning?  Or do you plan to provide it as a general tool?
> >>>>>
> >>>>> On 11-11-16 09:21 AM, Hans-Christoph Steiner wrote:
> >>>>>> Nathan and I were just discussing how best to proceed in terms of
> which OpenPGP implementation to use on Android.  Currently the only one is
> the pure Java APG.  Everywhere else, we are using GnuPG.  APG is a limited
> implementation of OpenPGP, it does not have methods for uploading personal
> public keys, signing other people's keys, or viewing certification
> signatures on a key. Additionally, APG does not have the privacy-enabling
> options like unexportable signatures or Web-Of-Trust enabling features like
> settable trust levels for keys that is independent from key certification.
> >>>>>>
> >>>>>> So at this point, we are thinking that our best option is to work
> solely with GnuPG, port it to Android, and use the existing GnuPG JNI
> bindings, improving them if need be.  Though we like the idea of supporting
> multiple implementations, APG just seems too immature for this current
> project.  Any comments or feedback is much appreciated.
> >>>>>>
> >>>>>> .hc
> >>>>>>
> >>>>>>
> ----------------------------------------------------------------------------
> >>>>>>
> >>>>>> Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.
>  It's about as sensible to say we declare war on night attacks and expect
> we're going to win that war.  We're not going to win the war on terrorism.
>        - retired U.S. Army general, William Odom
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Miron
> >>>>> http://hyper.to/blog/
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> ----------------------------------------------------------------------------
> >>>>
> >>>> "Free software means you control what your computer does. Non-free
> software means someone else controls that, and to some extent controls
> you." - Richard M. Stallman
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> --
> >>> Miron
> >>> http://hyper.to/blog/
> >>
> >>
> >>
> ----------------------------------------------------------------------------
> >>
> >> "A cellphone to me is just an opportunity to be irritated wherever you
> are." - Linus Torvalds
> >>
> >
> >
> > --
> > --
> > Miron
> > http://hyper.to/blog/
>
>
>
>
> ----------------------------------------------------------------------------
>
> There is no way to peace, peace is the way.       -A.J. Muste
>
>
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>        Or visit:
> https://lists.mayfirst.org/mailman/options/guardian-dev/sjlombardo%40zetetic.net
>
> You are subscribed as: sjlombardo at zetetic.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20111117/80f1115b/attachment.htm>


More information about the Guardian-dev mailing list