Likewise, Edwards DSA can be tortured into becoming a Curve25519 key.
But once you do that, *you're no longer using Edwards DSA*.
Can you be more specific why this is a problem?
I apologize in advance for sounding grumpy (I am, it's been an annoying
day so far) and condescending (which I'm
Am Freitag 07 Januar 2022 20:23:33 schrieb Robert J. Hansen via Gnupg-users:
> > There is anequivalence given (two functions) in the Ed25519 wikipedia
> > page, but I don't know if this allows the same curve used in both
> > algorithms.
> Likewise, Edwards DSA can be tortured into becoming a
There is anequivalence given (two functions) in the Ed25519 wikipedia page,
but I don't know if this allows the same curve used in both algorithms.
Yes, in the same way that if you torture a DSA key long enough you can
get the Elgamal encryption algorithm out of it. But once you do that,
On 07/01/2022 16:55, Bernhard Reiter wrote:
> Then RSA should be limited in the same way.
(Because there it is possible, so I guess that there is another reason.)
I agree, although IIRC such usage is supported for backwards
compatibility reasons.
| The curve is birationally equivalent to a
Am Freitag 07 Januar 2022 15:21:45 schrieb Andrew Gallagher via Gnupg-users:
> On 07/01/2022 14:06, Bernhard Reiter wrote:
> > With 2.2.33 is is not possible to create a single ecc key-pair
> > that can do "sign" and "encrypt".
>
> it is best practice to ke
I know that "ed25519" and "cv25519" are different algorithms,
but from my limited understanding the same key-pair should be
usable for both encrypting and signing in theory?
Ed25519 is (effectively) a Schnorr signature done over an Edwards curve.
Schnorr signatures have really no capability
On 07/01/2022 14:06, Bernhard Reiter wrote:
With 2.2.33 is is not possible to create a single ecc key-pair
that can do "sign" and "encrypt".
There are circumstances (legal, contractual, operational) where you may
need to disclose or share an encryption key, so it is be
With 2.2.33 is is not possible to create a single ecc key-pair
that can do "sign" and "encrypt".
I know that "ed25519" and "cv25519" are different algorithms,
but from my limited understanding the same key-pair should be
usable for both encrypting and
Hi Yutaka,
On 2021/09/17 03:30 PM, NIIBE Yutaka wrote:
> Baptiste Beauplat wrote:
> > I noticed that the key size reported by gpg --with-colons for ECC keys
> > (ed25519) have changed from 256 to 255.
>
> Thank you for sharing. I didn't know that it is exposed to users.
&g
is correct, despite the public key has a bitlength of 256.
/Ann.
Am 2021-09-15 um 20:30 schrieb Baptiste Beauplat via Gnupg-users:
> Hi,
>
> I noticed that the key size reported by gpg --with-colons for ECC keys
> (ed25519) have changed from 256 to 255.
>
> For instance, on my ke
Baptiste Beauplat wrote:
> I noticed that the key size reported by gpg --with-colons for ECC keys
> (ed25519) have changed from 256 to 255.
Thank you for sharing. I didn't know that it is exposed to users.
(I considered it were (only) internal thing in libgcrypt.)
> I was wondering
Hi,
I noticed that the key size reported by gpg --with-colons for ECC keys
(ed25519) have changed from 256 to 255.
For instance, on my key I previously got:
$gpg --with-colons -k lykn...@cilg.org | grep pub | cut -d : -f 3
256
While now the result is:
$gpg --with-colons -k lykn...@cilg.org
On Sun, 11 Apr 2021 20:32, karel-v_g--- said:
> Just out of curiosity one question: why did you "only" add curve x448
Because 25519 and 448 are the IETF standard curves. More curves are a
hassle for interoperability.
> from the SafeCurves project and not also E-521? For NIST and Brainpool
>
Hello!
The list of additions and changes to GnuPG 2.3 is quite impressive. Thanks for
all the work on GnuPG.
Just out of curiosity one question: why did you "only" add curve x448 from the
SafeCurves project and not also E-521? For NIST and Brainpool the available
curves >500bits are also
On 16/08/18 07:52, Felix E. Klee wrote:
> PS: I’m toying with the idea of switching from my smart card to a
> Trezor hardware token. This would mean generating an entirely new key
> (only 256 bit ECC supported).
I didn't look at the Trezor to check, but I'll assume it allows usage
w
Hi Damien,
I was referring to the discussion around RSA vs. ECC in
https://crypto.stackexchange.com/questions/60392/choice-of-ecc-curve-on-usb-token/60394#60394
I read several texts of people preferring RSA over ECC.
That's an excellent answer, thanks for posting this!
I've came up
Phil Pennock writes:
> On 2018-06-29 at 18:07 +0200, Damien Cassou wrote:
>> I'm not sure I want ECC after reading this:
>> https://crypto.stackexchange.com/a/60394/60027
>
> Curve25519 is not NIST ECC. It is ECC.
I was referring to the discussion around
On Fri, 29 Jun 2018 18:07, dam...@cassou.me said:
> Moreover, Nitrokey Storage only supports NIST and Brainpool, nothing
> else.
That is because the Nitrokey token includes a Zeitcontrol card which
only implements the government approved curves. If that ever changes we
can close the feature
On 2018-06-29 at 18:07 +0200, Damien Cassou wrote:
> NIIBE Yutaka writes:
> > Why not Curve25519, if you use ECC?
>
> I'm not sure I want ECC after reading this:
> https://crypto.stackexchange.com/a/60394/60027
Curve25519 is not NIST ECC. It is ECC.
"ECC" =
Hello Damien,
Am 2018-06-29 um 18:07 schrieb Damien Cassou:
> Moreover, Nitrokey Storage only supports NIST and Brainpool, nothing
> else.
Im not fully sure but i guess for your purposes you would need Nitrokey
Pro[1]
best regards
Juergen
[1]
NIIBE Yutaka writes:
> Why not Curve25519, if you use ECC?
I'm not sure I want ECC after reading this:
https://crypto.stackexchange.com/a/60394/60027
Moreover, Nitrokey Storage only supports NIST and Brainpool, nothing
else.
> Quite interesting opinion. [...]
thank you for the infor
Hello,
Why not Curve25519, if you use ECC?
Damien Cassou wrote:
> curves and (2) Bernstein’s Curve 25519 is hard to protect against side
> channel attacks when being implemented in embedded devices.
Quite interesting opinion. I wonder what kinds of side channel attacks
are dis
Hi,
I would like to get a usb token to secure my keys. My use case is
protection of 3 GnuPG keys that I will be using 10 times per day at
least. I plan to create a new key ring from scratch. Because ECC seems
more future-oriented than RSA, this is what I chose to use. I'm
wondering which usb
Hello.
I have one oif this new openPGP Cards v3.3 and yes, they are capable of
nist / brainpool only. curve25519 is not supported.
I use it only with RSA keys for compatiblity reasons. Not everybody
uses ECC capable versions of GnuPG or other compatible openPGP
software.
The card itself works
18:57, karel-...@tutanota.com wrote:
> Hello!
> I have seen that the latest revision of OpenPGP-cards (3.3) supports
> ECC-keys and is available for sale.
> Does this also include curve25519 or "only" Brainpool and NIST?
> Thanks
Hello!
I have seen that the latest revision of OpenPGP-cards (3.3) supports ECC-keys
and is available for sale.
Does this also include curve25519 or "only" Brainpool and NIST?
Thanks for enlightment!
Karel
___
Gnupg-users mailing list
G
On Fri 2017-12-29 01:18:27 +0100, Rezart Qelibari für GnuPG wrote:
> I want to batch generate a key using an ECC algorithm using the following
> command:
>
> $ cat config.txt | gpg —-batch —generate-key
for modern gnupg, i think what you want is:
gpg --quick-gen-ke
On Fri, 29 Dec 2017 16:53, gnupg-kont...@rezart.qelibari.de said:
> Thank you so much! This did the trick! I am very impressed.
I just added a mapping from the displayed names to the canonical names.
Thus with the next release (2.2.5) "ed25519" and "cv25519" should work.
Salam-Shalom,
Thank you so much! This did the trick! I am very impressed.
I don’t want to bother you too much, but maybe you can answer me the two
follow-up questions:
- How did you find out the protocol names, especially the upper case „E“ of
„Ed25519“ and that „cv25519“ is actually named „Curve25519“?
t; -k“ still yields „cv25519“. I find this behaviour very strange and unwisely.
The short answer is libgcrypt's cipher/ecc-curves.c , see line 45/46 for
mapping of shortnames to OIDs. Now, I agree this should at least be
case-insensitive, but there might be a feature request open for that
already :)
&
On 12/29/2017 01:18 AM, Rezart Qelibari für GnuPG wrote:
> Does anyone know what exactly goes wrong here?
try:
$ cat config.txt
Key-Type: eddsa
Key-Curve: Ed25519
Key-Usage: sign
Subkey-Type: ecdh
Subkey-Curve: Curve25519
Subkey-Usage: encrypt
Passphrase: somepassword
Name-Real: Some Real Name
Hi *,
I want to batch generate a key using an ECC algorithm using the following
command:
$ cat config.txt | gpg —-batch —generate-key
config.txt contains the following:
Key-Type: eddsa
Key-Curve: ed25519
Key-Usage: sign
Subkey-Type: ecdh
Subkey-Curve: cv25519
Subkey-Usage: encrypt
On Tue, 12 Dec 2017 02:47, nulik...@gmail.com said:
> I want to compile a lightweight version of libgcrypt with Public Key
> encryption using Elliptic curve cipher, but what do I feed on the
> ./configure command line for " --enable-ciphers" parameter? Is there a list
No
Hi all,
I want to compile a lightweight version of libgcrypt with Public Key
encryption using Elliptic curve cipher, but what do I feed on the
./configure command line for " --enable-ciphers" parameter? Is there a list
of ciphers? Can't find this info in README, INSTALL or the html docs.
If
quot;
ed25519 | awk -F: '/^fpr:/{ print $10 }')
This immediately runs gpg and ask for a password and creates an EdDSA
signing key without any errors.
> what version of gpg are you running when you see those warnings?
I run GnuPG 2.1.15 on Ubuntu 17.04. It is also possible to create an ECC
Hi Ryru--
On Wed 2017-05-31 18:18:56 +0200, Ryru wrote:
> I get these errors while trying to create a new ECC key:
>
> $ gpg --batch --gen-key Desktop/params-ecc.txt
> gpg: key ABCDEFABCDEFABCD marked as ultimately trusted
> gpg: error reading rest of packet: Invalid argume
Hi List
I get these errors while trying to create a new ECC key:
$ gpg --batch --gen-key Desktop/params-ecc.txt
gpg: key ABCDEFABCDEFABCD marked as ultimately trusted
gpg: error reading rest of packet: Invalid argument
gpg: error reading rest of packet: Invalid argument
gpg: can't encode a 256
enkey (ecc (curve \"NIST P-256\") (flags param
eddsa)))";
size_t erroff = 0;
/* Tell Libgcrypt that initialization has completed. */
gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0);
err = gcry_sexp_build(, , sexp);
if (err) {
fprintf(stderr, &quo
> Many Thanks, I can confirm that is works not as intended.
Oops, now, not not
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
> I hope to get 2.1.13 out this week, so please have some patience if you
> need a new installer.
>
> Thanks for reporting.
Many Thanks, I can confirm that is works not as intended.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
On Tue, 14 Jun 2016 at 23:17:59 +0200, Werner Koch wrote:
> On Tue, 14 Jun 2016 14:11, manto...@vollbio.de said:
>> This key has been created as a more or less default 3k RSA key, and I added
>> an
>> ECC encryption subkey with curve25519 after creation.
>> What I am
On Tue, 14 Jun 2016 14:11, manto...@vollbio.de said:
> This key has been created as a more or less default 3k RSA key, and I added an
> ECC encryption subkey with curve25519 after creation.
> What I am missing is the curve field filled for the subkey.
Ooops. Here is the fix I ju
Hi all,
I'm having issues with a mixed key (RSA+ECC subkey):
When I call "gpg --with-colons -k testkey" I get following result:
tru::1:1465904526:1481021465:3:1:5
pub:-:3072:1:25EA10972E695202:1464181218:::-:::scaESCA:::
uid:-1464181218::109E061B3DDEAAEDAC7C2444517BE0
Am 27.03.2015 um 14:21 schrieb Martin Behrendt:
On 26.03.2015 18:40, Pete Stephenson wrote:
People have raised concerns about the NIST curves, but they are part
of the RFC 6637 standard so compliant programs must implement P-256,
may implement P-384, and should implement P-521.
To address
On 27-03-2015 14:21, Martin Behrendt wrote:
So especially when introducing new algorithms which might be tampered
with, using e.g. an old style RSA Key as one layer and ECC as a second
should help against this. Or am I missing something here?
Why would you want to use a suspect algorithm
especially when introducing new algorithms which might be tampered
with, using e.g. an old style RSA Key as one layer and ECC as a second
should help against this. Or am I missing something here?
Greetings
Martin
___
Gnupg-users mailing list
Gnupg-users
The current version of Confidant Mail for Windows includes GPG 1.4.19.
However, the code is written to support version 2.1 and ECC keys. If you
point it to GPG 2.1, it will let GPG handle passphrases, and will let
you create and rotate ECC keys.
Is there any reason not to start using them? I
On 26-03-2015 9:59, Mike Ingle wrote:
Is this just a backward
compatibility thing, or is the security of ECC keys not fully trusted yet?
The buzz about Dual_EC_DRBG made it clear that it is possible to design
curves where the designers have access to data that allows them to
compromise
Hi,
is it possible to update an existing (RSA) gpg key to ECC?
Or would a usual transition process be required?
Cheers,
Patrick
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Am Fr 21.11.2014, 20:17:38 schrieb Patrick Schleizer:
is it possible to update an existing (RSA) gpg key to ECC?
Or would a usual transition process be required?
You can change the subkeys (encryption, signing) easily but not the
mainkey (the one the fingerprint refers to). But hardly any
there can use ECC now.
Newly-added ECC signing and encryption subkeys would be used in
preference by GnuPG 2.1; older GnuPG versions would ignore them and
use the older subkeys. And you can configure GnuPG 2.1 to sign with
both signing subkeys (or just the older subkey, but then what's the
point
it tries to decrypt ECC keys that
pointing to 0x, it seems to interpret it literally the message
intended to that key ID.
--
Hideki Saito
OpenPGP Key: http://hidekisaito.com/aff2e40b.txt
1066 3928 7B0B E7CD A0CB 3686 1FDF D937 AFF2 E40B
http://hidekisaito.com
Good morning/afternoon/evening.
I know that this has been discussed previously, but now that GnuPG modern
has been released with ECC support, is there the intention to add that
support to the classic build in the near-to-internediate future?
Thank you,
Avi
User:Avraham
pub 3072D/F80E29F9
I know that this has been discussed previously, but now that GnuPG
modern has been released with ECC support, is there the intention to
add that support to the classic build in the near-to-internediate
future?
The last this was discussed the answer was no. It's been some months
since
that GnuPG modern
has been released with ECC support, is there the intention to add that
support to the classic build in the near-to-internediate future?
No. It would be too hard. In case your problem is the pinentry: The
agent now provides a loopback pinentry option which basically brings
On Thu, 6 Nov 2014 16:15, avi.w...@gmail.com said:
I know that this has been discussed previously, but now that GnuPG modern
has been released with ECC support, is there the intention to add that
support to the classic build in the near-to-internediate future?
No. It would be too hard
On 06/11/14 17:45, Werner Koch wrote:
In case your problem is the pinentry: The agent now provides a
loopback pinentry option which basically brings back the version 1
Pinentry prompts.
Perhaps this warrants a mention on the what's new FAQ page, for people
that are using 1.4 for that specific
On Tue, 8 Jul 2014 09:56, bernh...@intevation.de said:
Do you also know the status of CMS (x.509) for S/MIME?
May work but likely needs a bit of testing and code fiddling. I have
lost most interest in CMS, thus better do not expect that I will spend
time on it.
Shalom-Salam,
Werner
to check out new
features and to fix the bugs in the last beta.
Congratulations on the new beta!
About th ECC support in GnuPG 2.1: Does this work with OpenPGP and
CMS?
ECC support for OpenPGP is defined in RFC6637[0]
With the same algorithms?
Only the NIST P-curves are currently
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/08/2014 09:56 AM, Bernhard Reiter wrote:
Kristian,
...
thanks for the pointers! Do you also know the status of CMS
(x.509) for S/MIME?
No, I don't pay too much attention to S/MIME as I have a *strong
preference* for OpenPGP myself
On Thursday 03 July 2014 at 12:05:07, Werner Koch wrote:
I just released the fifth *beta version* of GnuPG 2.1. It has been
released to give you the opportunity to check out new features and
to fix the bugs in the last beta.
Congratulations on the new beta!
About th ECC support in GnuPG 2.1
the bugs in the last beta.
Congratulations on the new beta!
About th ECC support in GnuPG 2.1: Does this work with OpenPGP and
CMS?
ECC support for OpenPGP is defined in RFC6637[0]
With the same algorithms?
Only the NIST P-curves are currently defined for OpenPGP although some
serpent
On Thu, 2 Jan 2014 18:54, eagleeyes...@yahoo.com said:
I have created a test ECC 25519 subkey.
You mean using the experimental code in GnuPG master? Don't use it - it
is is work in progress.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz
I have created a test ECC 25519 subkey.
If I encrypt a file sign a file to myself with gpg2 -esa
some_text.file it encrypts fine. But when trying gpg2 -v
some_text.file.asc I get the following error:
gpg: MyBuild
gpg: armor header: Version: GnuPG v2
gpg: public key is 3EF4
gpg: using subkey
On Tue, 2013-12-17 at 13:01 -0600, Anthony Papillion wrote:
I know that gnupg is experimenting with ECC and I'm wondering which
curves the team has decided to use. I know there are some curves that
are now suspected of being tainted by the NSA through NIST. Has the
gnupg team ruled using those
On Tue, 17 Dec 2013 20:01, anth...@cajuntechie.org said:
I know that gnupg is experimenting with ECC and I'm wondering which
curves the team has decided to use. I know there are some curves that
are now suspected of being tainted by the NSA through NIST. Has the
gnupg team ruled using those
I know that gnupg is experimenting with ECC and I'm wondering which
curves the team has decided to use. I know there are some curves that
are now suspected of being tainted by the NSA through NIST. Has the
gnupg team ruled using those curves out?
Anthony
--
Anthony Papillion
XMPP/Jabber
On Thu, 19 Sep 2013 20:59, jo...@netpage.dk said:
Yes, but it isn't only HIS stuff!
You have to trust the recipient anyway that he keep the information
confidential. It does not help to use string encryption if the message
is later re-tweeted by the recipient. Unfortunately this is too often
for the big fields in a non-user desperation time (I mean not bigger
but smaller than equivalent rsa generation).
/Sergi.
On Wed, Sep 11, 2013 at 1:46 PM, Alexandre Dulaunoy a...@foo.be wrote:
Hi Everyone,
Do you know if someone is currently working to implement additional
curves in ECC
On Thu, Sep 19, 2013 at 6:44 PM, Werner Koch w...@gnupg.org wrote:
to create the key (if that is possible) so that people can make a
judgement about that kind of thing when they certify keys -- assuming
If Bobs decides to use NIST curve, why don't you want to send a mail to
him. It his his
On Wed, Sep 18, 2013 at 9:06 AM, Werner Koch w...@gnupg.org wrote:
The standard already allows for all kind of curses. They are specified
by an OID and I offered DJB to assign OIDs from the GnuPG arc. The
original reason why I wanted an OID based design is so that it will be
possible to use
On Wed, Sep 18, 2013 at 9:33 AM, Josef Schneider jo...@netpage.dk wrote:
On Wed, Sep 18, 2013 at 9:06 AM, Werner Koch w...@gnupg.org wrote:
The standard already allows for all kind of curses. They are specified
by an OID and I offered DJB to assign OIDs from the GnuPG arc. The
original
implementation is more of a will to do it than a technical
challenge.
It's good to see that Werner has already made the suggestion to implement
different curves. Let's hope that the OpenPGP working group agrees with his
recommendation and that we can finally see (non-tampered with) ECC put
On Fri, Sep 13, 2013 at 08:17:11PM -0400, Robert J. Hansen wrote:
On 9/13/2013 6:20 PM, Werner Koch wrote:
No, I am not aware of any discussions. QC resistant algorithms are not
yet something we need to rush for.
Although it hasn't hit the IETF WG mailing list, I know that some list
in Libgcrypt.
Very nice. Support for Curve25519 would make me far more likely to use
ECC in GnuPG. Doubts about NIST curves aside, it has security features
not present in e.g. P-256. It's also a lot faster.
Nicolai
___
Gnupg-users mailing list
Gnupg-users
.
There are of course sound reasons why they suggest the use of ECC. With
about 30 years of research, ECC has a pretty solid theoretical
foundation. The reasons why the seeds for the NIST curve parameters
have not been recorded should of course raise more doubts now - I don't
think
On Thu, 12 Sep 2013 07:35, d...@fifthhorseman.net said:
GnuPG 2.1 (still currently in beta, afaict) is the first version to
include ECC support for OpenPGP. the 2.0.x branch does not include ECC
Right. There are no plans to support it in older versions. 2.1 also
has a feature to work
On 9/13/2013 8:52, Werner Koch wrote:
concerns about switching to GnuPG-2. However, if at some time ECC would
really take off, we might backport it to 1.4 if we could agree to change
1.4 to make use of Libgcrypt.
Such a major change would warrant a 1.6 IMO.
BTW, is there any discussion
IMO ECC has at least some questions about it since the NSA is pushing
it. That could be because they know of weaknesses in it, or because they
There are of course sound reasons why they suggest the use of ECC. With
about 30 years of research, ECC has a pretty solid theoretical
foundation
On 9/13/2013 6:20 PM, Werner Koch wrote:
No, I am not aware of any discussions. QC resistant algorithms are not
yet something we need to rush for.
Although it hasn't hit the IETF WG mailing list, I know that some list
participants have had intermittent off-list conversations about lattice
Hi Everyone,
Do you know if someone is currently working to implement additional
curves in ECC
and especially to have an alternative to the NIST ones in gcrypt/GnuPG?
and I was wondering if we are bound to the ones defined in:
http://tools.ietf.org/html/rfc6637#section-11
Thank you,
Cheers
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
Your selection? ^C
gpg: signal Interrupt caught ... exiting
Shouldn't I be seeing 1 or more ECC choices?
Was I supposed to supply some special arguments to ./configure ?
Thanks
On 09/11/2013 11:43 PM, Newton Hammet wrote:
Shouldn't I be seeing 1 or more ECC choices?
GnuPG 2.1 (still currently in beta, afaict) is the first version to
include ECC support for OpenPGP. the 2.0.x branch does not include ECC
for OpenPGP.
Regards,
--dkg
signature.asc
Description
Am So 23.06.2013, 21:44:50 schrieb Werewolf:
Is it possible to have 2 active subkeys?
ie say an ecc and an ElGamal for encryption?
Yes.
--
☺
PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04)
http://www.openpgp-courses.org/
signature.asc
Description
Is it possible to have 2 active subkeys?
ie say an ecc and an ElGamal for encryption?
--
Werewolf
=- http://www.nyx.net/~mdkeith/ -
GPG key 0xF52A14B4 with following fingerprint
35CD 0611 2F71 BC17 5C53 29A2 5F5A 4309 F52A 14B4
=- http://spandex31095.tripod.com
Hi,
i know that there is an option for ECC available when using the developer
version with --expert command switch. The problem is i cannot compile it.
Not on MinGW and not on my linux web server.
Well, i actually fail to compile libgpg-error-1.11. On linux i get during
make
libtool: compile
On a related note, Sascha's message reminded me of something: is there
any word on when the OpenPGP+ECC standard (RFC 6637) is going to be
finalized/approved?
I, for one, am really interested in ECC as it'd allow for stronger
security without outrageously-large RSA keys. I'd hate to go through
On Tue, 18 Dec 2012 20:21, phonetree...@gmail.com said:
I was not able to find anything in the manual about it though. I
searched and searched for the details on how to get on with using it,
$ gpg2 --expert --gen-key
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for
On Mon, 17 Dec 2012 03:14, phonetree...@gmail.com said:
Hey, I found the discussion in this newsgroup linked to below. It
was last posted to in 2010. Looked like ECC support was coming, but
as far as I can tell GPG doesn't support ECC yet. Is it on it's way?
It is supported since
...@gnupg.org
To: Thomas Demers phonetree...@gmail.com, gnupg-users@gnupg.org
Date: Tue, Dec 18, 2012 at 5:00 AM
Subject: Elliptic curves in gnupg status?(ECC support)
On Mon, 17 Dec 2012 03:14, phonetree...@gmail.com said:
Hey, I found the discussion in this newsgroup linked to below
Hey, I found the discussion in this newsgroup linked to below. It
was last posted to in 2010. Looked like ECC support was coming, but
as far as I can tell GPG doesn't support ECC yet. Is it on it's way?
I was just thinking maybe the messages could be short enough yet
moderately secure
On 17-12-2012 3:14, Thomas Demers wrote:
I was just thinking maybe the messages could be short enough yet
moderately secure, to send over SMS, due to the shorter key sizes?
There is an open source Java application that implements ECC public key
encryption with SMS: http://cryptosms.org/ (don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 17/12/12 16:04, Johan Wevers wrote:
I was just thinking maybe the messages could be short enough yet
moderately secure, to send over SMS, due to the shorter key
sizes?
There is an open source Java application that implements ECC public
Hi folks,
I've updated paperkey to work with elliptic curve OpenPGP keys. I would really
appreciate it if anyone out there could give this devel version a try (either
with ECC or regular keys, or ideally both).
Source: http://www.jabberwocky.com/software/paperkey/paperkey-1.3-devel.tar.gz
Forwarding this message originally sent to sks-devel as it can have
relevance for gnupg-users as well.
Original Message
Subject: sks-keyservers.net: ECC safe subpool
Date: Sun, 07 Oct 2012 22:59:54 +0200
From: Kristian Fiskerstrand kristian.fiskerstr...@sumptuouscapital.com
On Tue, 15 May 2012 16:50, avi.w...@gmail.com said:
them temporarily each time if necessary. Allowing an option to have
the home and other helper directories configured as a subfolder of the
install directory on the install should be helpful as well. What I
I agree. We could do this. If a
On Tue, May 22, 2012 at 5:15 AM, Werner Koch w...@gnupg.org wrote:
On Tue, 15 May 2012 16:50, avi.w...@gmail.com said:
them temporarily each time if necessary. Allowing an option to have
the home and other helper directories configured as a subfolder of the
install directory on the
On Tue, 22 May 2012 17:29, avi.w...@gmail.com said:
That would be great! To close the loop, could the installer be
modified to ask if the current install is portable and then create
that file before the rest of the install to make it seamless?
I am not keen to add yet another visible option.
On Mon, 14 May 2012 23:53, avi.w...@gmail.com said:
anything to work, as I am not able to figure out how to us gpgconf to
switch sysconfdir to my stick's drive, and everything else is failing
The directory is determined by looking at CSIDL_COMMON_APPDATA. It
seems you can change the value by
On Tue, May 15, 2012 at 5:33 AM, Werner Koch w...@gnupg.org wrote:
On Mon, 14 May 2012 23:53, avi.w...@gmail.com said:
anything to work, as I am not able to figure out how to us gpgconf to
switch sysconfdir to my stick's drive, and everything else is failing
The directory is determined by
1 - 100 of 132 matches
Mail list logo
