Seahorse
I am a regular user of KDE and KGPG. I tried to ride seahorse, but I find
the interface very confusing. I found out how to encrypt/decrypt, after some
struggle and experimentation. I am still not able to sign/verify a file. How
do I do that ? Why cant interface designers make things a little less
enigmatic :{ ?
partha
--
View this message in context:
http://old.nabble.com/Seahorse-tp29902685p29902685.html
Sent from the GnuPG - User mailing list archive at Nabble.com.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seahorse
On 10/6/2010 11:21 PM, drpartha wrote:
Why cant interface designers make things a little less enigmatic :{
During grad school I did a few semesters of human-computer interface
(HCI) design, particularly with respect to OpenPGP user interfaces.
It's a fascinating subject but ultimately left me very, very cynical.
Here's why.
[sets the rant switch to ENGAGED]
The reason why user interfaces suck: crypto is hard, making good user
interfaces is hard, the OpenPGP spec is human-unfriendly, and there is
an enormous resistance in the community to newer and better interfaces.
Consider signatures on a user ID. A signature issued by someone you
don't trust is utterly meaningless. It's noise. There are a couple of
possible use cases (e.g., trying to find ways to connect two disjoint
webs of trust, or mapping out a target's social network), but those are
pretty niche when compared to average users and their needs.
So, already, one way to make interfaces simpler: omit all untrusted
signatures. If a signature doesn't contribute to the overall trust
calculation on a key, don't display it -- reduce the cognitive spam.
Another culprit: we've now got about 15 years of experience with a
really awful user interface that should have never been fielded.
Unfortunately, that interface has now become standard, and any attempt
to change it will get pushback from users.
Table-oriented data is principally useful in two conditions:
non-interactive interfaces and contextual views.
In non-interactive interfaces (like printed almanacs), all the data has
to be visible all the time. If I want to look up the population of
Zimbabwe, well, the almanac can't interactively ask me the country I'm
looking for. It has no option but to present all countries, and give me
a user interface that makes it possible to find what I'm looking for.
In contextual views (like Excel spreadsheets), the data in one area is
contextualized with information from another area. When looking at a
business's profit-and-loss statement, it's useful to be able to
immediately see how much each business unit contributed to the bottom
line. Or, in your email client, it's useful to be able to see your
emails in chronological order: the sequence in which they arrived is
contextual information relevant to each email.
So... consider the traditional OpenPGP certificate management interface.
It presents all these certificates in an enormously complex tabular
format. Click on a certificate and it reveals user IDs and subkeys.
Click on a user ID or a subkey and it reveals signatures. Etc., etc., etc.
This interface is user-hostile. There are two compelling reasons to use
tabular data -- noninteractive interfaces and contextual data -- and
neither of them applies to OpenPGP certificates. The key manager is an
interactive interface, and if I'm looking at certificate 0xDEADBEEF I
really don't give half a damn about 0xDECAFBAD, 0xBADD00D5, or
0xBADF00D5... so why am I getting cognitively spammed with information
about them?
Unfortunately, PGP 5.0 presented all certificates to the user in this
tabular format -- and ever since, that's what users have demanded. It's
what they know, it's what they want, and if you seriously suggest
getting rid of a table view people will refuse to use your interface.
At the end of the HCI course I had a prototype key manager that avoided
the table widget and ruthlessly suppressed useless data. It consisted
of pretty much just a search box into which you could type an email
address, a certificate ID, a user name, a comment, whatever. Once you'd
narrowed your certificates under a dozen, a list would pop up showing a
certificate ID, the best-matching user ID on the certificate, and its
trust level. Double-click on an element in the list and bang, a
certificate editor appeared, with helpful wizards to walk you through
the process of validating a key, uploading it to a key server, etc., etc.
Ultimately it was just a prototype: it was never a fully functional
certificate manager. Two things convinced me to let this project die
and not pursue it further. One was there was a strange problem
involving GnuPG refusing to communicate via a pipe with Java. The
problem strongly appeared to be in GnuPG. Ultimately, that's a minor
problem.
The real downer came when I showed long-time GnuPG users this interface.
Opinions ran about five to one, hey, this is a really sweet interface,
and I like it -- but it'd be even better if there was a big table widget
with all my certificates there. I'd use that instead. I'm familiar
with that user interface!
... I should point out, BTW, that although being told don't make a
better interface, make it just like the interfaces we know is a downer,
I'm not faulting people one bit for it. People have invested a lot of
time and effort in learning these bad, broken, user-hostile interfaces.
It is *absolutely* reasonable for them to want to use an interface they
know, rather than learn yet another
What's the best way to test a long list of passphrases?
Hi, I have a GPG key to which I've forgotten the passphrase. That is, I remember the mnemonic I used, but not the particular set of l33tspeak substitutions and punctuation used, and guessing hasn't worked. It's a ~26 character passphrase, and since I know the options I might have used I was able to write a perl script to generate the 30,000 or so possible permutations that I might have used. Given that, what's the best way for me to test my 30,000 possible passphrases? I'd prefer to ask gnupg directly via some API (I'm fine writing a small C program if I know the relevant functions to use) rather than trying to script around the text ui (and it's 1-second delay after input). Any suggestions? -will ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What's the best way to test a long list of passphrases?
On Thu, 2010-10-07 at 15:28 +, Will McDonald wrote: Hi, I have a GPG key to which I've forgotten the passphrase. That is, I remember the mnemonic I used, but not the particular set of l33tspeak substitutions and punctuation used, and guessing hasn't worked. It's a ~26 character passphrase, and since I know the options I might have used I was able to write a perl script to generate the 30,000 or so possible permutations that I might have used. Given that, what's the best way for me to test my 30,000 possible passphrases? I'd prefer to ask gnupg directly via some API (I'm fine writing a small C program if I know the relevant functions to use) rather than trying to script around the text ui (and it's 1-second delay after input). Any suggestions? -will ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users http://www.gnupg.org/related_software/libraries.en.html see gpgme libgcrypt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What's the best way to test a long list of passphrases?
On 10/7/2010 11:28 AM, Will McDonald wrote: Given that, what's the best way for me to test my 30,000 possible passphrases? At one per second, it'll take about nine hours. Your fastest solution involves spend the rest of today polishing the script, and letting it run overnight. Slow and stupid wins. The smart and fast way involves doing the s2k computations yourself and checking prospective keys one after another, but even then this will be slow. The s2k computation involves a lot of iterated hashing in order to slow down brute force attempts like this. You'll waste more time writing code than you'll gain by a faster algorithm. Basically, if you do things the slow and stupid way you'll be done by morning. If you do things the smart and fast way you might be finished by the end of the week. You can view this as an instance of worse is better. Good luck! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
batch file automation -Nearly There!
SETLOCAL
PATH=C:\Program Files (x86)\GNU\GnuPG;%PATH%
%TMP%\~encryptlist.txt DIR /B C:\outgoingdropfolder
PUSHD C:\outgoingdropfolder
FOR /F delims= %%F IN ('MORE ^ %TMP%\~encryptlist.txt') DO (
IF EXIST %%F (
ECHO bingos| GPG --batch -se --passphrase-fd 0 -r PGPTOKEY -o
C:\encryptedfiles\%F.pgp
IF ERRORLEVEL == 0 DEL %%F
)
)
POPD
DEL %TMP%\~encryptlist.txt
ENDLOCAL
above is the script im using to try and automate GPG (bingos is not my real
password) the above is working sort off
let me explain what i want it to do
a User can drop any type of file, called anything they like into the
dropfolder, when the batch runs, i want the file (or files) to be encrypted
(all with the same encryption and signing key) and then outputted to the folder
called encrypted files, the file names must be the same as they were when they
went in, except obviousley the new pgp extension. (i require the output to be a
PGP extension)
This is what happens when i run the above batch.
I drop a file called lee.txt (10mb) into dropfolder, run the batch, the file
dissapears from drop folder, and appears in the encypted files folder with the
file name f.PGP ? and is only 1kb in size ?
the encryptlist.txt appears to be working fine. Im hoping that it will be able
to handle more than one file ( I asume that is what the encrypt list is for ?
) however im unable to confirm as the files are becoming over written when they
get to encrypted folder. If i drop 2 files at the same time then the encrypted
list does pick up 2 different file names.
I can confirm that encyption and signing is working as it should, i can
suucesfully decypt and verify signature using PGP, (but like i said, the file
is empty)
Hope ive explained clearly enough, thanks to all that have helped me get to
this stage.
Lee
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What's the best way to test a long list of passphrases?
On 10/7/2010 7:08 PM, Reid Thompson wrote: given that -- split the file into 5? chunks and kick off 5? copies of the script Given the amount of time required to write a multithreaded application that intelligently divides up work units across cores, versus the eight hours for a single-threaded, single-cored version... There's an old rule of thumb about not using more hammer than you need for a given nail. Tacks get tackhammers and railroad spikes get sledgehammers, but it's foolish to drive tacks with sledges or spikes with tackhammers. This is a tack problem. Use a tackhammer. smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What's the best way to test a long list of passphrases?
On 10/7/2010 3:25 PM, Robert J. Hansen wrote: On 10/7/2010 11:28 AM, Will McDonald wrote: Given that, what's the best way for me to test my 30,000 possible passphrases? At one per second, it'll take about nine hours. Your fastest solution involves spend the rest of today polishing the script, and letting it run overnight. Slow and stupid wins. The smart and fast way involves doing the s2k computations yourself and checking prospective keys one after another, but even then this will be slow. The s2k computation involves a lot of iterated hashing in order to slow down brute force attempts like this. You'll waste more time writing code than you'll gain by a faster algorithm. Basically, if you do things the slow and stupid way you'll be done by morning. If you do things the smart and fast way you might be finished by the end of the week. You can view this as an instance of worse is better. Good luck! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users given that -- split the file into 5? chunks and kick off 5? copies of the script ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
