Ingo Klöcker kloecker at kde.org wrote on
Wed Mar 23 22:39:05 CET 2011 :
>So, out of 2^2048 candidates you eliminate 1+2+...+300 = 300*301/2
=
45150 candidates which lie in those intervals. Impressive!
lol!
like I said,
4096 bit keys will remain secure for the not-too-near future
ved
On Wednesday 23 March 2011, ved...@nym.hush.com wrote:
> Jerome Baum jerome at jeromebaum.com wrote on
>
> Tue Mar 22 23:28:31 CET 2011 :
> >They go up with O(log(n)) where n is the number, or
>
> something like it, right?
>
>
> The Prime Number Theorem:
>
> Pi(x) ~ x/ln(x)
> (Pi(x) ref
Jerome Baum jerome at jeromebaum.com wrote on
Tue Mar 22 23:28:31 CET 2011 :
>They go up with O(log(n)) where n is the number, or
something like it, right?
The Prime Number Theorem:
Pi(x) ~ x/ln(x)
(Pi(x) refers to the number of primes up to and including the
integer x
~ means approx
On Tuesday 22 March 2011, Jerome Baum wrote:
> Jonathan Ely writes:
> > I really wish 8192 would become available. Not that it would be the
> > end all/be all of key security but according to your theory it
> > sounds much more difficult to crack.
>
> Take that a few steps further. Why not use
On Tuesday 22 March 2011, Robert J. Hansen wrote:
> On 3/22/11 5:50 PM, Jerome Baum wrote:
> > Actually none of this is that important. If you can do the
> > division in half a second instead of one, that only halves the
> > time you need. All I have to do is add one bit to my key size
> > a
On Wed, 23 Mar 2011 03:33, jpcli...@tx.rr.com said:
> Could be in OpenPGP later this year. Camellia was fairly fast.
It is not required to be in in OpenPGP (technically a new RFC to extend
rfc4880). We have always added new features to OpenPGP before we had an
RFC for it. It is basically, that
Jerome Baum wrote:
> Grant Olson writes:
>
>> On 03/22/2011 06:06 PM, Jonathan Ely wrote:
>>> I really wish 8192 would become available. Not that it would be the end
>>> all/be all of key security but according to your theory it sounds much
>>> more difficult to crack.
>>>
>>
>> The actual cutti
On Tue, Mar 22, 2011 at 5:14 PM, Mike Acker wrote:
> with chip makers playing with chips having 64 cores printed in silicon...
>
> someplace i read the ratios on this,-- if you make the key a little
> longer the key gets much harder to break. in public key encryption
> though you have to factor t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/22/2011 06:32 PM, Jonathan Ely wrote:
> What is ECC? Now I want that haha.
Elliptic curve cryptography
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using
Grant Olson writes:
> On 03/22/2011 07:44 PM, Jerome Baum wrote:
>> Grant Olson writes:
>>> ECC actually is up-and-running in the beta for gpg 2.1, but
>>> realistically it'll be (at least) a few years before it gets mainstream
>>> adoption.
>>
>> You loose any interoperability as it's not Ope
On 03/22/2011 07:44 PM, Jerome Baum wrote:
> Grant Olson writes:
>> ECC actually is up-and-running in the beta for gpg 2.1, but
>> realistically it'll be (at least) a few years before it gets mainstream
>> adoption.
>
> You loose any interoperability as it's not OpenPGP, right? It certainly
> is
On 03/22/2011 07:32 PM, Jonathan Ely wrote:
> What is ECC? Now I want that haha.
>
Elliptic Curve Cryptography
https://secure.wikimedia.org/wikipedia/en/wiki/Elliptic_curve_cryptography
Since it isn't based on prime numbers, it 'scales' better than RSA or
DSA, and keys of similar security level
On 03/22/2011 07:29 PM, Robert J. Hansen wrote:
> On 3/22/2011 6:53 PM, Grant Olson wrote:
>> The actual cutting edge solution is to move from RSA to ECC. Even a
>> 8192 bit or 16k bit RSA key isn't approved by the NSA or NIST for TOP
>> SECRET materials, but ECC-521 is.
>
> Do you have a cite fo
On 3/22/2011 7:44 PM, Jerome Baum wrote:
> Isn't ECDSA really vulnerable to reused and predictable signature
> seeds (don't know what they're called, I'm talking about "k")?
No moreso than many other algorithms. If the algorithm says "this value
must be random" and you don't use a random value,
Grant Olson writes:
> On 03/22/2011 06:06 PM, Jonathan Ely wrote:
>> I really wish 8192 would become available. Not that it would be the end
>> all/be all of key security but according to your theory it sounds much
>> more difficult to crack.
>>
>
> The actual cutting edge solution is to move fr
What is ECC? Now I want that haha.
On 22/03/2011 06:53 PM, Grant Olson wrote:
> On 03/22/2011 06:06 PM, Jonathan Ely wrote:
>> I really wish 8192 would become available. Not that it would be the end
>> all/be all of key security but according to your theory it sounds much
>> more difficult to crac
On 03/22/2011 06:06 PM, Jonathan Ely wrote:
> I really wish 8192 would become available. Not that it would be the end
> all/be all of key security but according to your theory it sounds much
> more difficult to crack.
>
The actual cutting edge solution is to move from RSA to ECC. Even a
8192 bit
On 3/22/2011 6:53 PM, Grant Olson wrote:
> The actual cutting edge solution is to move from RSA to ECC. Even a
> 8192 bit or 16k bit RSA key isn't approved by the NSA or NIST for TOP
> SECRET materials, but ECC-521 is.
Do you have a cite for that? I know ECC is approved, but I've never
been able
"Robert J. Hansen" writes:
> You have to add one bit to your *effective* key size. Remember, the
> primes are not evenly distributed: the larger you go, the more they are
> spread out. This is why for very small keys each additional bit gives
> you quite a lot of security, but as keys grow very
On 3/22/11 5:50 PM, Jerome Baum wrote:
> Actually none of this is that important. If you can do the division in
> half a second instead of one, that only halves the time you need. All I
> have to do is add one bit to my key size and you're back to square
> one.
You have to add one bit to
Jonathan Ely writes:
> I really wish 8192 would become available. Not that it would be the end
> all/be all of key security but according to your theory it sounds much
> more difficult to crack.
Take that a few steps further. Why not use 999-bit
keys? Because they are much
I really wish 8192 would become available. Not that it would be the end
all/be all of key security but according to your theory it sounds much
more difficult to crack.
On 22/03/2011 05:14 PM, Mike Acker wrote:
> with chip makers playing with chips having 64 cores printed in silicon...
>
> somepla
with chip makers playing with chips having 64 cores printed in silicon...
someplace i read the ratios on this,-- if you make the key a little
longer the key gets much harder to break. in public key encryption
though you have to factor the product of the two large prime numbers --
which i'm told i
Mike Acker writes:
> with chip makers playing with chips having 64 cores printed in silicon...
>
> someplace i read the ratios on this,-- if you make the key a little
> longer the key gets much harder to break. in public key encryption
> though you have to factor the product of the two large pri
limited by the card firmware. For each crypto
operation, a data block with the same size as the key needs to be
transferred to the card, which needs to have buffer space available for
the data.
While the crypto processor itself can handle 4096 bit keys, the code
running on the card that implements
On Wed, 2010-04-28 at 19:37 +0200, Joke de Buhr wrote:
> Is there any way of transferring my existing 4096 bit keys to the card.
> Generating new 3072 bit keys worked fine but it would be a lot better if I
> could stick to my 4096 keys.
Obviously not...
Cheers,
Chris.
smime.p7s
De
hi,
I recently purchased this usb gnupg smart card
https://www.privacyfoundation.de/crypto_stick/
Within an email developers stated the usb stick itself could handle keys with
a length of 4096 but gnupg doesn't support these key lengths.
Is there any way of transferring my existing 409
27 matches
Mail list logo
