Pehr Jansson wrote:
> Please remove me from this mailing list.
>
Visit the URL that is written at the bottom of each message sent to the
list and remove yourself.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/
Sven Radde <[EMAIL PROTECTED]> writes:
>
> In fact, some mathematician has proven that factoring is a polynomial
> problem, IIRC.
>
No, what they have proven is that *primality testing* is a polynomial problem.
http://en.wikipedia.org/wiki/AKS_primality_test
__
"Jim Berland" <[EMAIL PROTECTED]> writes:
>
> There are other flaws in the computer system that would have to be
> addressed (a secretary has root access to the server to let her start
> the daily backup process after work), but I'm not in charge of that. I
>
Huh? That requires only a single suid
"Robert J. Hansen" <[EMAIL PROTECTED]> writes:
>>
>> What prevents the keylogger in your first example to snarf the PIN
>> code
>> for the OpenPGP card and send decryption requests to the OpenPGP card,
>> using the PIN code, in the background, possibly remotely controlled
>> over
>> the networ
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
We[1] are pleased to announce the availability of PKCS#11 support for gpg2. The
first release that we deem decent enough to be publicly released can be found
at the following link:
http://gnupg-pkcs11.sourceforge.net/
[1] Me and Alon Bar-Lev ar
Alphax wrote:
>
> I don't suppose any keyserver operators could tell us the specs on their
> machines...
>
IMO, more important factor is the number of uploaded keys per hour or
day. If a keyserver receives e.g. 100 keys per day, this work could be
easily handled by 486/66MHz.
signature.asc
Desc
Alphax wrote:
>
> However, the keyserver would then have to verify the signature of the
> uploading key... how much of an extra burden would this be?
>
In what way "extra burden"? Computationally (CPU), programming
complexity, or...?
Computationally - it would be done only oncem on key upload. I
Pawel Shajdo wrote:
>
> I think this is public more keyservers design problem than GD. Keyserver
> should accept new signatures only from key owner.
>
Hm, maybe to define a "key upload format" which must be signed with the
uploaded key itself (analogon of PKCS#10)? Of course, the public key
itse
Alon Bar-Lev wrote:
Great! Super! Amazing!
If you can do it with a little effort I will glad to check and use it.
Not so little. I don't have any card or PKCS#11 driver. Mozilla NSS is a
pain to set up. I have no idea how to use its softtoken implementation.
Opencryptoki uses ^$@@#$$#&^!!ng au
Alon Bar-Lev wrote:
>
But the work needs to be moved into gpg-agent... :(
You were referring to my PKCS#11 patch.. After studying the GPG
architecture a bit, I think this needs to be moved into the scdaemon.
gpg-agent actually does nothing with smart-cards - it uses scdaemon to
do the work.
Wh
David Picon Alvarez wrote:
There is not point in writing a low level code in each application to
support each card it is NxN situation, not wise.
The truth is that if cards were more ISO compliant this situation would not
be a big deal.
Even if this were to happen, ISO still doesn't say anyt
Alphax wrote:
1. What's the standard size of the EEPROM on a smartcard suitable for
OpenPGP?
YOu have cards ranging from 8k to 64k
>
2. What else could you fit on such a card?
debit/credit applications, X.509 PKI applications, data-containers, etc.
>
3. Is it possible to have multiple th
Alon Bar-Lev wrote:
When you raise this issue... It seems that PKCS#11 is not implemented not
because of licensing problems... But because if PKCS#11 will be implemented
then there will be no work to be done for each specific card...
But this strategy can, and will
backfire :) From personal
Alon Bar-Lev wrote:
Again... I am sorry but I must disagree... WHERE THE CODE RUN IS NOT AN
ISSUE.
The issue is how tightly your code is with another code.
A protocol and API specification are the same, since they can replace one
another...
I would agree with this. Why does the actual _mechan
'Lionel Elie Mamane' wrote:
Please do so. I'm curious how you will handle:
1) Pointers being passed
By copying the whole address space back and forth at each call and
return? "Morally" that's not running in separate address spaces!
Make the programs share their _data_ segments, but
Zeljko Vrba wrote:
>
PKCS#11 IS a library API. But really, how is API different from a
protocol? Is the only difference linking in the same address space?
BTW, I can imagine writing a version of ld.so (BSD licensed!) that will
execute different shared libraries as separate processes, and w
Alphax wrote:
Zeljko Vrba wrote:
Joe Smith wrote:
For example, your CA can revoke your key leaving you with one key that
is invalid X.509, but valid OpenPGP? Yuck!
Using the X.509 cert and OpenPGP public key (having the same private
key) could be useful in the following scenario:
Is
'Lionel Elie Mamane' wrote:
I had understood that it was not a _protocol_ but a library API. HTTP
is a _protocol_ for data interchange over the network. I thought
PKCS#11 was a _library_ API and that you linked (dynamically at
run-time) a particular "implementation" of it (the card driver) into
Joe Smith wrote:
For example, your CA can revoke your key leaving you with one key that
is invalid X.509, but valid OpenPGP? Yuck!
Using the X.509 cert and OpenPGP public key (having the same private
key) could be useful in the following scenario:
1. You must periodically pay to your CA to re
Alon Bar-Lev wrote:
I agree... So if we all understand the need of PKCS#11 in order to access
cryptographic tokens, what I don't understand is how come people choose to
develop low-level applications in order to work with specific devices?
Neither do I understand that. Werner didn't give a sin
Alon Bar-Lev wrote:
Zeljko wrote:
IMHO, PKCS#11 has succeeded where ISO7816 has failed: providing a
(relatively) simple way to interface with many smart-card implementations,
And I've forgot to mention one thing that may be important to some
people: PKCS#11 is not limited to smart-cards. If
Alon Bar-Lev wrote:
I use Athena smartcard www.athena-scs.com which works perfectly in term of
Linux and PKCS#11. I enjoy using it with Java JCE, Mozilla, Tunderbird,
PAM_PKCS11, I've encrypted my disk using aes-loop and then required gpg to
support PKCS#11... And here we are...
Great! When I
Peter Gutmann wrote:
I'd already offered the use of my PKCS #11 interface code from cryptlib for
GPG use some time ago. This should do everything you need and has had years
of tuning to work with all the bugs in various PKCS #11 drivers, it's vastly
easier than going through the entire learning
Greg Sabino Mullane wrote:
I should have said "whose systems bounce (or discard!) emails with
attachments."
I can say that I've worked in such company. Oddly enough, the server
seemed to strip only the application/pgp, or whatever the MIME type is,
replacing it with some bogus MS-TNEF attachme
Kara wrote:
What would be an equally good equivalent
for those of us using a Linux distro?
You can use loop-aes, I think it's included in 2.6 kernels. I would
recommend BestCrypt from www.jetico.com. It is not free software, but
fully-functional evaluation version for download is available (so
Chris De Young wrote:
some GPG encryption output (with -a, e.g. "QhRuM+W4xC9qnPvn") might be a good
source of password material.
It's random-looking to the untrained eye, but how random is it really? It
>
1. I know that this isn't what you were asking but you can get the same
result by using
Sven Fischer wrote:
Also, it isn't our fault, that M$ does use such simple crypto algorithms. I
personally share this opinion, but only for the encryption side. For
decryption, I don't understand why it should be a problem.
For decryption there is no problem, of course. As for encryption.. it
Werner Koch wrote:
IIRC, we would need to implement a variant of RC2 to allow this. And
well, 40 bit RC2 keys are pretty ridiculous.
Ugh, I hope that you'll _never,ever_ allow such low-grade insecure
algorithms in gpg or anything related to it, no matter what the public
demand is.
best regar
Werner Koch wrote:
Well for the OpenPGP card you don't need any filesystem as we onjly
use the get/put data commands. Thus a simple offset,length table is
what you need. Well, you know that of course.
Yeah, I know that very well :) It took me a bit of time to correctly
implement the coding/d
Werner Koch wrote:
On Fri, 22 Jul 2005 23:42:39 +0200, Felix E Klee said:
isn't that interesting, though. The point is that AFAICS PKCS#11
clearly defines an API, and perhaps it may become an ISO standard in the
No it does not define a clean API. Almost everyone is using
proprietary extensi
Felix E. Klee wrote:
Huh? AFAICS, in general it is more important to have the subkeys on a
smart card than the master key. After all the master key can be stored
>
But then you cannot commit a mortal sin of using GPG remotely ;)
Seriously, I think you have a very strong point in case of keepi
Werner Koch wrote:
On Fri, 22 Jul 2005 19:01:57 +0200, Felix E Klee said:
Uh, I guess this would cost me too much time. One solution, though,
would be to buy a JavaCard and try to run and enhance the OpenPGP Java
implementation that was started by Zeljko Vrba [3].
Java cards do have some
Felix E. Klee wrote:
I'd like to do PGP with a Smartcard that contains my main private key (I
I have made a patch to support 3rd party smart-cards with GPG using
PKCS#11 interface.
In the mean time I have abandoned the development, however another kind
individual has picked up from where I hav
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Greg Reaume wrote:
|
| I searched the mailing list archive and came up with an individual
| that has attempted this:
| http://www.core-dump.com.hr/index.pl?lastnode_id=404&node_id=421
|
I am that individual :) I managed to get it generate the key
34 matches
Mail list logo
