xpg-devel — development discussion

[xPG] GUI library proposal

[Marcel S. <sc...@ta...>]

Hello there,

I just stumbled over your xPG project on Sourceforge. Since it seems
to be still in an early phase, I'd like to give some input to the
issue of GUI development for the client.

It would be great if any GUI client would support not only J2SE
platforms (like PCs, Macs, Linux-boxes etc.) but also PersonalJava /
PDA platforms. Maybe you'd like to check out this cool free
lightweight GUI library:

http://www.zaval.org/products/lwvcl/index.html

Other than "normal" lightweight Java GUI components, it implements
an additional layer to abstract from the AWT, so it can be ported
to non-AWT platforms too. It currently supports PocketPCs like the
Sharp Zaurus or Compaq iPAQ as well. It's still pretty small
(140 KB) for a GUI lib with some complex elements too
(Swing-like table, tree control etc.)

Regards,
Marcel Schoen

-- 
Marcel Schoen                                   sc...@ta...
TARSEC AG                                       Tel +41 1 496 61 11
Rautistrasse 12                                 Fax +41 1 496 61 99
8047 Zürich, Switzerland                        http://www.tarsec.com

Re: [xPG] project state

[Sven <fi...@na...>]

hi all,
no.
greetings
sven 

Ingo Luetkebohle schrieb:
> 
> Hi,
> 
> xPG looks pretty much dead.  Any objections to formally disbanding
> it (i.e., deleting the project from sourceforge)?
> 
> Ingo
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> xPG-devel mailing list
> xPG...@li...
> https://lists.sourceforge.net/lists/listinfo/xpg-devel

Re: [xPG] project state

[Frank L. <fra...@we...>]

On Wed, 20 Nov 2002 15:57:26 +0100
Ingo Luetkebohle <in...@fa...> wrote:
> xPG looks pretty much dead.  Any objections to formally disbanding
> it (i.e., deleting the project from sourceforge)?

No objections.

Frank

-- 
God gave man two ears and one tongue so that we listen twice 
as much as we speak.
-- Arab Proverb

[xPG] project state

[Ingo L. <in...@fa...>]

Hi,

xPG looks pretty much dead.  Any objections to formally disbanding
it (i.e., deleting the project from sourceforge)?

Ingo

Re: [xPG] Ideas behind gui

[M.Jerger <mj...@we...>]

Hi,


> 1. Usability:
Ack, thaths hight prior.

> 2. Architecture:
> Our/My approach was to have two layers:
> - an ui-layer
> - an engine(layer) that encapsulates the cryptographic functions and the
> configuration.
An extendet MVC, I think is state of the Art.

> the glue between the 2 layers should be (swing)-models (table, tree)
> that adapts the xpg-engine-classes to the ui.

Ack.

> xpg.tool.ui - the base ui-package
> xpg.tools.ui.swing - for the main classes of the swing-ui
> xpg.tools.ui.swing.engine - the stuff for the engine (not quit right
> here, imho should be changed in the future to xpg.tools.ui.engine)
> and a sub-package for each of the tabpanes (preferences, keys, crypt/
> decrypt ...)
>
> if you want to add an alternate ui use by example xpg.tools.ui.j2me .

Miracles will happen soon :-)

> finally a few words to the directory-structure of the project.
> in the project-dir there is an ant-script for:
>  - building and running the ui (imho targets "compile" and "ui.swing")
>  - creating the javadoc
>  - preliminary support for java-webstart
>  - test runs with junit-classes (target "test" - mostly used by ingos
> xpg-classes)
>  - build of the distribution (does some additiona stuff)
>
> in the lib-subdir there should be all used jar-files for building and
> executing.
> docs is for additional documentation.

thanks :-)


ciao
micha

Re: [xPG] New Member

[M.Jerger <mj...@we...>]

Hi,

> Well, its this cell-battery sized java cpu with some RAM on it that
> connects serially to any host.  See http://www.ibutton.com/

I can remember it, I've heared about iButton about 3 years ago.
Is there any market for this button ? I think the price is an realy 
heavy for this peace of hardware.

> 	:pserver:an...@fa...:/var/cvs
> (empty password)

I've done this already.

> If you want, you could get started on the Builder classes.  As I said,
> it should not be too much effort, it will familiarize you with the
> OpenPGP standard and its fairly independent of the work the others are
> doing.  It would also really boost the functionality quickly.

I'l do a brif look at. First of all I'l do some test with the libs maybe 
there will be such an Builder after all :-)

> > - How can I get the hidden cvs stuff ?
>
> What do you mean by that?  I'm not aware of a "hidden cvs" :-)

Errr, with httpCvs I can see more files (e.g. the Attic stuff) then I get 
with the real CVS and behind that files there is an  "(hidden)" remark.


by
micha

Re: [xPG] Ideas behind gui

[Frank L. <fra...@we...>]

Hi,

Some short words of mine to the gui ideas.

1. Usability: 
The ui should be as simple as possible to use. 
Thats why we have only a few tabbed panes with the basic functions
(similar to gpg/gpa).

2. Architecture:
Our/My approach was to have two layers:
- an ui-layer
- an engine(layer) that encapsulates the cryptographic functions and the
configuration.
the glue between the 2 layers should be (swing)-models (table, tree)
that adapts the xpg-engine-classes to the ui.

at this time this idea isn't consequently used in all parts of the (my)
code. 
Some things should be done in another (cleaner) way.
the idea behind the layered approach was to support alternate ui-s (if
somebody will write it :) )
(awt, j2me - uses midlets or some things like that?).

the ui-stuff is structured as followed:

xpg.tool.ui - the base ui-package
xpg.tools.ui.swing - for the main classes of the swing-ui
xpg.tools.ui.swing.engine - the stuff for the engine (not quit right
here, imho should be changed in the future to xpg.tools.ui.engine)
and a sub-package for each of the tabpanes (preferences, keys, crypt/
decrypt ...)

if you want to add an alternate ui use by example xpg.tools.ui.j2me .

finally a few words to the directory-structure of the project.
in the project-dir there is an ant-script for:
 - building and running the ui (imho targets "compile" and "ui.swing")
 - creating the javadoc
 - preliminary support for java-webstart
 - test runs with junit-classes (target "test" - mostly used by ingos
xpg-classes)
 - build of the distribution (does some additiona stuff)

in the lib-subdir there should be all used jar-files for building and
executing.
docs is for additional documentation.

Regards, Gulliver

Re: [xPG] New Member

[<in...@fa...>]

On Fri, Dec 07, 2001 at 07:21:57AM +0100, M. Jerger wrote:
> Will xPG be an entire substitution for gnupg ?

If someone gets around to implementing the stuff, yes ;-) The Cryptix
OpenPGP lib is already pretty good feature-wise but its lacking v3
(i.e., pgp 2.6) compatibility when writing.
 
> What's iButton ? The infamous java-micro-processor ?

Well, its this cell-battery sized java cpu with some RAM on it that
connects serially to any host.  See http://www.ibutton.com/
 
> - Can you give me a short overview of the cvs ?

I'll do it for the library stuff, gulliver hopefully jumps in and does
it for the ui stuff.  

Some general info: Browse the CVS through
	http://fargonauten.de/cgi-bin/viewcvs
Anonymous CVS is at 
	:pserver:an...@fa...:/var/cvs
(empty password)

So, firstly forget the "openpgp-provider" stuff, all you want is in
"xpg".  The top-level stuff should be self-explanatory.  The stuff in
src/xpg/ is as follows:
	block    -- a couple of interfaces for generic crypto format access
	openpgp  -- An openpgp-implementation of those interfaces, mostly complete
	provider -- A generic Certificate, C-Factory and KeyStore based on the 'block'
		    interfaces, currently slightly openpgp specific

	test	 -- JUnit test cases, testing data, etc.

The idea behind the 'block' interfaces is that we want to support the
PKCS family of standards, too, eventually, and the interfaces are
supposed to be the unifying layer.

> - Can I generate an new private Key, encrypt something and then also decrypt ?

Of course you can do that using the JCE, but the result can not yet be
written as OpenPGP packets..  Let me explain:
	
The stuff in xpg.openpgp can read the OpenPGP-packet format and the
result of that are immutable packet objects.  The state of the art is
that these provide enough information to get keys and data *out* -- so
you can decrypt and check signatures.  To create packets from
JCE-level objects, a couple of "Builder" classes are planned that will
do the necessary conversions and then create immutable packet objects
again.  This has not yet happened.  Its actually not too much effort
but I wanted to get the reading part feature-complete first.

If you want, you could get started on the Builder classes.  As I said,
it should not be too much effort, it will familiarize you with the
OpenPGP standard and its fairly independent of the work the others are
doing.  It would also really boost the functionality quickly.

On a side note, one final obstacle to writing is that we don't have a
BlockOutput that will generate a stream of packets.  I estimate that
to be a couple of hours of work for v4, have a look at the
SignatureOutput for the general idea.

> - How can I get the hidden cvs stuff ?

What do you mean by that?  I'm not aware of a "hidden cvs" :-)

Ingo

Re: [xPG] New Member

[M.Jerger <mj...@we...>]

Hi,

> [In short: xPG is what you make of it.]

Will xPG be an entire substitution for gnupg ?

> That said, items currently being worked on are a low-level OpenPGP
> implementation (me), some baseline GUI stuff (gulliver) and I also

Okay, I found that xpg.tools.ui.swing stuff. Does gulliver still some work 
with it, or is this part of code sleeping ?

> have some iButton-based token supporting code lying around that I want
> to generalize a bit to encompass all crypto-tokens and then integrate

What's iButton ? The infamous java-micro-processor ?

> it.  Someone else was also working on Smartcard stuff but he seems to
> have vanished.

Smartcard sounds great :-) but there is typical no display on there ... 
so crypto dosn't seem realy usefull for me.

> Looking at your experience, maybe you'd be interested in looking into
> the J2ME stuff?  Then, again, maybe you'd like something else for a
> change ;-)

I think J2ME (the political correct name now is CLDC) sounds intresting.
But I'm a friend of small finished steps. Will say, if the JDK1.3 based 
lib's are finished and stable, I'l try my luck doing that port.

> I have been investigating the possibility to build a low-level lib on
> something like the BouncyCastle leight-weight (non-JCE) crypto library
> for use with J2ME but didn't pursue that further because I didn't have
> a J2ME development environment.  Since our pgp library does not make

Okay, if you're interestet, you may search at the sun 
java-developer-connection for "j2me wireless toolkit" and additional 
for the palm emulator to run.

Finaly I'l need your help:
- Can you give me a short overview of the cvs ?
- Can I generate an new private Key, encrypt something and then also decrypt ?
- How can I get the hidden cvs stuff ?


by
micha

Re: [xPG] New Member

[<in...@fa...>]

Hi Michael,

welcome to the list!

First off, let me say that xPG does not have fixed goals or something
like that.  Its more of a collaboration, code- and idea-sharing
between people building cryptographic user-level (be that GUI or
server-side) applications in Java utilizing OpenPGP.  Thats a very
broad agenda but its probably specific enough to differentiate
ourselves from other groups.  In short: xPG is what you make of it.
This is something of a change from our original agenda (which was
building a PGP replacement in Java) but more closely matches what the
developers currently involved are actually capable of doing while
still having fun.

That said, items currently being worked on are a low-level OpenPGP
implementation (me), some baseline GUI stuff (gulliver) and I also
have some iButton-based token supporting code lying around that I want
to generalize a bit to encompass all crypto-tokens and then integrate
it.  Someone else was also working on Smartcard stuff but he seems to
have vanished.

Looking at your experience, maybe you'd be interested in looking into
the J2ME stuff?  Then, again, maybe you'd like something else for a
change ;-)

On Thu, Dec 06, 2001 at 08:50:17AM +0100, M. Jerger wrote:
> - What's the target plattform for the gui ?

Not really fixed but the library currently required JDK 1.3, so thats
what we got.

I have been investigating the possibility to build a low-level lib on
something like the BouncyCastle leight-weight (non-JCE) crypto library
for use with J2ME but didn't pursue that further because I didn't have
a J2ME development environment.  Since our pgp library does not make
many assumptions, it really should not be too hard but its mostly an
application issue anyway.  I also don't know how the cryptix
high-level (messaging) stuff fares with regard to JDK requirements,
maybe Edwin can enlighten us there.  This will be mostly be of
interest for the agent, I think and considering the limited
functionality for that area, we might make it a completely seperate
implementation and then look at what part of the implementation could
be shared afterwards.

Apart from that, it sort of went without saying that GUIs are intended
to run on most desktop systems (MacOS 9 will be tough) eventually and
that the agent (and thus the crypto-token support) should run on most
mobile systems.

> - How do you communicate the application designs ? (UML, maybe an
> specialized tool or file format) ?

Code ;-) Really, I did some screenshots a while back of how a GUI
could look like and we're mostly just going ahead with an ad-hoc
design, post patches and then let it be discussed.  If you want to use
UML, thats fine, but its not required IMHO.

Ingo

[xPG] New Member

[M.Jerger <mj...@we...>]

Hi

to all, I'm new in this list and would like to support your
gui-developement :-)

First of all, there are some questions:
- What's the target plattform for the gui ?
- What's the concrete environment (plattform & scenario) for the
crypt-/decrypt-suite ?
- How do you communicate the application designs ? (UML, maybe an specialized
tool or file format) ?

After all the questions, maybe my backgound would also be intresting for you:
- About 9 y's I'm out in the buiz doing some database stuff.
- Since '96 I became familiar with Java and OO.
- Actually I'm designing and implementing an java-based portability framework
for mobiles (smart phones, handhelds, notebooks up to server based).


cheers
micha

[xPG] CVS messages

[Ingo L. <in...@fa...>]

Hiya,

sorry for the CVS message, I was just testing around.

Ingo

P.S. More details on mvoe and new snapshot soon.

[xPG] [cvs] commit xpg/src/xpg/provider

[<in...@fa...>]

ingo	Monday October 29, 2001 @ 23:07
Update of /var/cvs/xpg/src/xpg/provider
In directory fargonauten.de:/tmp/cvs-serv26597

Modified Files:
	SpiLoader.java 
Log Message:
typo fix to make clear that 1.3 specific stuff is used

[xPG] [xPG-cvs] commit xpg/src/xpg/openpgp

[<in...@fa...>]

ingo	Monday October 29, 2001 @ 23:00
Update of /var/cvs/xpg/src/xpg/openpgp
In directory fargonauten.de:/tmp/cvs-serv26406

Modified Files:
	AlgorithmConstants.java EncryptedDataPacket.java 
	KeySpecFactory.java 
Log Message:
Type	   | feature

 - Support for the special OpenPGP-CFB mode through cfb.OpenPGPParameterSpec
 - Now uses SecretKeySpec instead of DESedeKeySpec to cope with providers
   that don't have a KeyFactory for DESede (e.g., Cryptix JCE)


===================================================================
File: no file AlgorithmConstants.java		Status: Needs Checkout

   Working revision:	1.6	Mon Oct 29 22:00:41 2001
   Repository revision:	1.6	/var/cvs/xpg/src/xpg/openpgp/AlgorithmConstants.java,v

   Existing Tags:
	No Tags Exist

===================================================================
File: no file EncryptedDataPacket.java		Status: Needs Checkout

   Working revision:	1.2	Mon Oct 29 22:00:41 2001
   Repository revision:	1.2	/var/cvs/xpg/src/xpg/openpgp/EncryptedDataPacket.java,v

   Existing Tags:
	No Tags Exist

===================================================================
File: no file KeySpecFactory.java		Status: Needs Checkout

   Working revision:	1.4	Mon Oct 29 22:00:41 2001
   Repository revision:	1.4	/var/cvs/xpg/src/xpg/openpgp/KeySpecFactory.java,v

   Existing Tags:
	No Tags Exist

[xPG] [xPG-cvs] commit xpg/src/xpg/openpgp/s2k

[<in...@fa...>]

ingo	Monday October 29, 2001 @ 22:58
Update of /var/cvs/xpg/src/xpg/openpgp/s2k
In directory fargonauten.de:/tmp/cvs-serv26385

Modified Files:
	StringToKey.java 
Log Message:
Type	   | fix

 - Handles ciphers with key-lengths > digest-length
 - Fixed mode for initialization of underlying cipher


===================================================================
File: no file StringToKey.java		Status: Needs Checkout

   Working revision:	1.6	Mon Oct 29 21:58:09 2001
   Repository revision:	1.6	/var/cvs/xpg/src/xpg/openpgp/s2k/StringToKey.java,v

   Existing Tags:
	No Tags Exist

[xPG] [xPG-cvs] commit xpg/src/xpg/openpgp/cfb

[<in...@fa...>]

ingo	Monday October 29, 2001 @ 22:54
Update of /var/cvs/xpg/src/xpg/openpgp/cfb
In directory fargonauten.de:/tmp/cvs-serv26345

Modified Files:
	OpenPGP.java 
Log Message:
Type	   | fix

 - Implemented IV's correctly
 - Now delegates to the empty doFinal() method of the underlying cipher
   on empty input


===================================================================
File: no file OpenPGP.java		Status: Needs Checkout

   Working revision:	1.2	Mon Oct 29 21:54:35 2001
   Repository revision:	1.2	/var/cvs/xpg/src/xpg/openpgp/cfb/OpenPGP.java,v

   Existing Tags:
	No Tags Exist

[xPG] [xPG-cvs] commit xpg/src/xpg/openpgp/cfb

[<in...@fa...>]

ingo	Monday October 29, 2001 @ 22:51
Update of /var/cvs/xpg/src/xpg/openpgp/cfb
In directory fargonauten.de:/tmp/cvs-serv26326

Modified Files:
	OpenPGPParameterSpec.java 
Log Message:
Type	   | bugfix

Changed package name


===================================================================
File: no file OpenPGPParameterSpec.java		Status: Needs Checkout

   Working revision:	1.2	Mon Oct 29 21:51:22 2001
   Repository revision:	1.2	/var/cvs/xpg/src/xpg/openpgp/cfb/OpenPGPParameterSpec.java,v

   Existing Tags:
	No Tags Exist

Re: [xPG] passphrase again and again

[Frank L. <fra...@we...>]

Hi, folks,

sorry for the delay, i've got a "too many open Baustellen"-Error. :)
 
After some little changes i've now checked in rubens passphrase-input
classes .

In general it isn't a good idea to make a swing-component (JCheckBox)
static. 
Especially for sharing a state (or data) between several instances of a
Dialog.
This is now fixed. 
The Engine class (@see getOptions) is the right place for storing all
states(data) 
of xpg so adding an Option "hide passphrase typing" to it was a better
idea IMHO.
So the "hide passphrase typing"-Option its also in the preferences panel
automatically. 

The passPhrase-input reads the initial state via the mainFrame from the
engine.
Selection/ deselection of the checkbox sets the state in the engine.

There is now an additional xpg.util.CharArray class. 
It deletes the internal char array for security reasons before setting a
new one 
and cleans itself before it goes to the orcus of gc. :)
A static clear method can ovwerwrite the contents of a primitive char[]
-
this is now used by the engine and PassPhraseInput.

The MainMenu has got an Entry [edit]->[Enter Passphrase] for testing
purposes.

As far as i can see these are all changes.
Must prepare for the bread-and-butter-stuff in the morning and go to
bed.

Nice Work done, Ruben.

Regards, Frank

Re: [xPG] (no subject)

[Ingo L. <in...@bl...>]

On Tue, Oct 09, 2001 at 03:55:22PM +0200, Ruben Malchow wrote:
> because with a LayoutManager, i would need more components to structure the 
> existing ones. since the dialog is not resizable anyway (at the moment) i 
> wouldn't think that's necessary.

Think i18n...

Anyway, so far I've heard no objections from gulliver and will commit
the dialog now.

Ingo

[xPG] (no subject)

[Ruben M. <ru...@un...>]

 >noch 'ne Frage -- warum machst Du diese "setBounds" Sachen und dann
 >auch noch mit statischen Werten? Sollte der Layout-Manager das nicht
 >automatisch anorden?

because with a LayoutManager, i would need more components to structure the 
existing ones. since the dialog is not resizable anyway (at the moment) i 
wouldn't think that's necessary.

changes:

- abort() is now public
- comments added
- isHideTyping() now returns a boolean instead of void and no longer
	calls setHideTyping. instead, the ActionListener for the checkbox
	has been changed to do setHideTyping(isHideTyping())
- several loops overwriting the internal char[] have been replaced with calls
	to clearPassPhrase() - which actually does the same.
- the "hide typing" checkbox is now static.

.rm

[xPG] passphrase again

[Ruben M. <ru...@un...>]

ok,

some minor stuff:

- entering a correct password in the last retry now works.
- removed all System.err.printlns from the relevant classes

.rm

[xPG] (no subject)

[Ruben M. <ru...@un...>]

hello list,

ok, now this is the PassPhraseInput with a JPasswordField. is the 
finalize() thing ok? one problem is: even with long passphrases, i can't 
see what i'm actually typing, and the JPasswordField is a single-line ...

.rm

Re: [xPG] cryptix-openpgp and OptionsTable()

[Ruben M. <ru...@un...>]

hi,


>I would recommend implementing a special text-input component that
>writes its input into a dynamically allocated char array.  KeyStore
>expects its input as a char-Array and the array can be overwritten
>with 0 after usage.  You can do that by hooking into the Keyboard
>event processing, check out JTextComponent.

problem is: if i use JTextArea (or JTextComponent) - i could override 
processKeyEvent() - i would still have to display it somehow. if i used 
setText() for that and have the Component display the text, i'd have to 
instantiate a String to use as parameter, plus i couldn't be sure how it is 
handled internally.

so, basically, i'd have to extend Canvas or something, keep a char[] 
internally and draw the letters myself (one by one). but i'd still have the 
single letters as Strings (which shouldn't be that much of a problem).

>Another issue is about the method naming.  I would recommend following
>the Java Beans naming guidelines as that will make the component
>easier to use in GUI builders.  For example, instead of "hideTyping"
>and "checkHideTyping" you would provide "setHideTyping(boolean)" and
>"isHideTyping" (or maybe correct the grammar ;-) Check out the
>JavaBeans introduction (can be found in the JDK documentation) for
>more information.

those are private, dammit :) but i've changed them, anyway.

.rm

Re: [xPG] cryptix-openpgp and OptionsTable()

[Ingo L. <in...@bl...>]

Hi Ruben,

On Sat, Oct 06, 2001 at 11:49:49AM +0200, Ruben Malchow wrote:
> 8. anbei bisserl doofer dialog + testapp (hihi).

I looked at the code and one issue is that you are using Strings.
This is quite natural as text-input boxes in Swing return Strings but
in this special case, it has the problem that Strings are immutable.
Therefore, the can't be overwritten after usage and the passphrase
will be left lying around in memory somewhere.  As the passphrase is
quite sensitive and must not be leaked, special handling is needed.

I would recommend implementing a special text-input component that
writes its input into a dynamically allocated char array.  KeyStore
expects its input as a char-Array and the array can be overwritten
with 0 after usage.  You can do that by hooking into the Keyboard
event processing, check out JTextComponent.

Another issue is about the method naming.  I would recommend following
the Java Beans naming guidelines as that will make the component
easier to use in GUI builders.  For example, instead of "hideTyping"
and "checkHideTyping" you would provide "setHideTyping(boolean)" and
"isHideTyping" (or maybe correct the grammar ;-) Check out the
JavaBeans introduction (can be found in the JDK documentation) for
more information.

Ingo