[guardian-dev] Gibberbot keystore format

Hans-Christoph Steiner hans at guardianproject.info
Wed Aug 15 09:06:46 EDT 2012



On 08/15/2012 12:24 AM, Miron wrote:
> On 14/08/12 12:59, Hans-Christoph Steiner wrote:
> 
>> I was thinking about this a little more.  If I recall, you're in
>> the process of integrating SQLCipher into Gibberbot.  Then I think
>> it makes sense to switch the keystore over to a SQLCipher database,
>> then allow Gibberbot to import/export using a well-known file
>> format.  If that's what you were proposing before, I totally missed
>> that.
> 
> Yup, sorry if I was unclear.
> 
> 
>> Gibberbot should at minimum be able to read its own file format,
>> but if it wasn't much work, then it would make sense to add direct 
>> importing of Pidgin files.  Reading the Pidgin file format is 
>> documented and implemented in the OTRFileConverter, so it could be 
>> pretty easy.
> 
> The only issue is that Pidgin doesn't have a pubkey column (only
> fingerprint).  Should we just add a column to it?  I can check if
> Pidgin will ignore the extra column.

All of the libotr-based clients work without storing the remote public
keys, only the fingerprint.  I think it'll be much less work to just
make Gibberbot work using only the fingerprint as well.  I was under the
impression that you already did that in order to support importing
gibberbot keystore files that were generated from libotr files.

>> Then we'd just need to figure out how the import/export process 
>> actually works, mostly in terms of how to securely copy the files 
>> around.
> 
> I was thinking of piping directly into APG for export (APG will let
> you email it).  We can also register a specific extension so that on
> decryption APG automatically routes it to Gibberbot.  I have to check
> if this is all done securely - i.e. that APG does not store plaintext
> on flash.
>
> To clarify, the purpose of going through APG (or your GPG JNI effort) is
> to ensure that encryption/decryption happens in memory and never touches
> the flash.  It has nothing to do with PSST (although PSST might end up
> with a similar RAM based flow for constructing / unpacking subkeys).

This sounds like a good approach to try first.  My concern with this
approach is that it requires PGP email in order to send keys to the
phone.  But we can figure out how to make an easy import process later,
whether its PGP-based or not.

.hc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20120815/1829b5d4/attachment-0001.pgp>


More information about the Guardian-dev mailing list