info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Generating GPG keys on ancient laptop
79 views
Skip to first unread message
Dänk 42Ø
Nov 22, 2016, 5:31:49 AM11/22/16
to
I dug out an ancient 1995 laptop with no wifi or internet connection. I
am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
install the latest GPG 2.1.16 testing without the compromised ECC
function from NIST/NSA (same thing). (Ironically, the only thing I
trust NIST for is to give me the correct atomic time of day.)
My plan is to generate several dozen 4096 GPG keys (do they go higher?).
Totally offline, and I don't care if takes months to generate them. I
figure that every microprocessor since 1995 has been compromised by the
NSA, which is why I dug out that ancient laptop. (Never throw seemingly
obsolete electronics away -- stick them in a Faraday Cage just in case).
The goddamn CD-Rom is still installing Debian 8 to the 6G hard drive!
This could take all night! And another month to generate all the keys
I might want to use in the future.
Can GPG 2.1.16 testing generate uncompromised keys on such an old
computer? Also, for fixed (single-key) file encryption, which of the
various algorithms do y'all recommend? Anything with the remotest
connection to the U.S. government is unacceptable.
am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
install the latest GPG 2.1.16 testing without the compromised ECC
function from NIST/NSA (same thing). (Ironically, the only thing I
trust NIST for is to give me the correct atomic time of day.)
My plan is to generate several dozen 4096 GPG keys (do they go higher?).
Totally offline, and I don't care if takes months to generate them. I
figure that every microprocessor since 1995 has been compromised by the
NSA, which is why I dug out that ancient laptop. (Never throw seemingly
obsolete electronics away -- stick them in a Faraday Cage just in case).
The goddamn CD-Rom is still installing Debian 8 to the 6G hard drive!
This could take all night! And another month to generate all the keys
I might want to use in the future.
Can GPG 2.1.16 testing generate uncompromised keys on such an old
computer? Also, for fixed (single-key) file encryption, which of the
various algorithms do y'all recommend? Anything with the remotest
connection to the U.S. government is unacceptable.
William Unruh
Nov 22, 2016, 5:41:15 AM11/22/16
to
On 2016-11-22, D??nk 42?? <da...@coffee.amsterdam.com> wrote:
> I dug out an ancient 1995 laptop with no wifi or internet connection. I
> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
> install the latest GPG 2.1.16 testing without the compromised ECC
> function from NIST/NSA (same thing). (Ironically, the only thing I
> trust NIST for is to give me the correct atomic time of day.)
Since you are paranoid, why in the world would you trust GPG software?
> I dug out an ancient 1995 laptop with no wifi or internet connection. I
> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
> install the latest GPG 2.1.16 testing without the compromised ECC
> function from NIST/NSA (same thing). (Ironically, the only thing I
> trust NIST for is to give me the correct atomic time of day.)
>
> My plan is to generate several dozen 4096 GPG keys (do they go higher?).
of keys that small.
> Totally offline, and I don't care if takes months to generate them. I
> figure that every microprocessor since 1995 has been compromised by the
> NSA, which is why I dug out that ancient laptop. (Never throw seemingly
> obsolete electronics away -- stick them in a Faraday Cage just in case).
is far far easier to compromise than hardware.
>
> The goddamn CD-Rom is still installing Debian 8 to the 6G hard drive!
> This could take all night! And another month to generate all the keys
> I might want to use in the future.
>
> Can GPG 2.1.16 testing generate uncompromised keys on such an old
> computer? Also, for fixed (single-key) file encryption, which of the
> various algorithms do y'all recommend? Anything with the remotest
> connection to the U.S. government is unacceptable.
Everything has the "remotest connection".
d the specifications and code your own. Of course all of bugs you
introduce will make it easy to crack, but you cannot make an omelette
with out breaking some eggs.
FromTheRafters
Nov 22, 2016, 11:14:42 AM11/22/16
to
Dänk 42Ø explained :
> I dug out an ancient 1995 laptop with no wifi or internet connection. I
> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
> install the latest GPG 2.1.16 testing without the compromised ECC
> function from NIST/NSA (same thing). (Ironically, the only thing I
> trust NIST for is to give me the correct atomic time of day.)
IMO ECC can be trusted, just watch your Ps and Qs.
> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
> install the latest GPG 2.1.16 testing without the compromised ECC
> function from NIST/NSA (same thing). (Ironically, the only thing I
> trust NIST for is to give me the correct atomic time of day.)
David Eather
Nov 22, 2016, 8:54:54 PM11/22/16
to
possible(by those working within or for the US government)??
FromTheRafters
Nov 22, 2016, 10:44:33 PM11/22/16
to
David Eather laid this down on his screen :
Yes, I did. I was under the impression that the OP was referring to the
'backdoor' aspect of having a known relation between the P and Q values
as a default.
What is wrong with it now?
'backdoor' aspect of having a known relation between the P and Q values
as a default.
What is wrong with it now?
Dänk 42Ø
Nov 23, 2016, 3:58:53 AM11/23/16
to
standards agencies we are in big trouble.
Dänk 42Ø
Nov 23, 2016, 6:57:47 PM11/23/16
to
On 2016-11-22 10:40, William Unruh wrote:
> On 2016-11-22, D??nk 42?? <da...@coffee.amsterdam.com> wrote:
>> I dug out an ancient 1995 laptop with no wifi or internet connection. I
>> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
>> install the latest GPG 2.1.16 testing without the compromised ECC
>> function from NIST/NSA (same thing). (Ironically, the only thing I
>> trust NIST for is to give me the correct atomic time of day.)
>
> Since you are paranoid, why in the world would you trust GPG software?
Because it is open-source, and the main components have been digitally
> On 2016-11-22, D??nk 42?? <da...@coffee.amsterdam.com> wrote:
>> I dug out an ancient 1995 laptop with no wifi or internet connection. I
>> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
>> install the latest GPG 2.1.16 testing without the compromised ECC
>> function from NIST/NSA (same thing). (Ironically, the only thing I
>> trust NIST for is to give me the correct atomic time of day.)
>
> Since you are paranoid, why in the world would you trust GPG software?
signed by trusted keys. (There are a few loose ends, which is why Ip
rely on the trusted signatures for the dozen or so Debian packages
needed to compile it; which is why I am up all night again.)
Hackers take encryption seriously, which is why any flaw in the source
code had been found it already have been published. No, I can't read
C++ code, but others can. If there were a backdoor in the software,
somebody would have discovered it already.
But if the government has access to the hardware -- the CPU used to
compile the encryption software -- the compiled software can be easily
compromised. Just think for a moment: When was the last time you
heard of the U.S government filing antitrust lawsuits against Intel
or AMD? Or the various manufacturers of ARM?
David Eather
Nov 23, 2016, 8:43:24 PM11/23/16
to
On Wed, 23 Nov 2016 16:51:46 +1000, Dänk 42Ø <da...@coffee.amsterdam.com>
wrote:
NIST got the recommended ECC curves from the NSA where they were generated
by an expert in EC. That much is known.
Conjecture:
As of past behavior the NSA tries to hand out as many 'free' back-doors as
it can to people who trust them if it believes no one else can gain
advantage. The NIST curves may have that type of back door. Perhaps it is
a fault similar to that exploited for DH in BULLRUN. Somewhere/Somehow the
method to crack these in a reasonable time has leaked. Is the FSB so
incompetent that it didn't spot a guy storing 40TB of data in his garage?
Who knows, but the timing is interesting. All of a sudden there is a
problem. They either have to admit they supplied everyone technology with
a back door at a time when the population is wary and untrusting of being
watched by their government or they simply have to say that all ECC is
unsafe, which now forces everyone back to DH and RSA. In this advent the
NSA still has some relative advantage because of their heavy investment in
super computers.
wrote:
by an expert in EC. That much is known.
Conjecture:
As of past behavior the NSA tries to hand out as many 'free' back-doors as
it can to people who trust them if it believes no one else can gain
advantage. The NIST curves may have that type of back door. Perhaps it is
a fault similar to that exploited for DH in BULLRUN. Somewhere/Somehow the
method to crack these in a reasonable time has leaked. Is the FSB so
incompetent that it didn't spot a guy storing 40TB of data in his garage?
Who knows, but the timing is interesting. All of a sudden there is a
problem. They either have to admit they supplied everyone technology with
a back door at a time when the population is wary and untrusting of being
watched by their government or they simply have to say that all ECC is
unsafe, which now forces everyone back to DH and RSA. In this advent the
NSA still has some relative advantage because of their heavy investment in
super computers.
Richard Kettlewell
Nov 24, 2016, 4:29:32 AM11/24/16
to
Dänk 42Ø <da...@coffee.amsterdam.com> writes:
> Hackers take encryption seriously, which is why any flaw in the source
> code had been found it already have been published. No, I can't read
> C++ code, but others can. If there were a backdoor in the software,
> somebody would have discovered it already.
http://www.dest-unreach.org/socat/contrib/socat-secadv7.html took about
> Hackers take encryption seriously, which is why any flaw in the source
> code had been found it already have been published. No, I can't read
> C++ code, but others can. If there were a backdoor in the software,
> somebody would have discovered it already.
a year to be discovered and fixed. http://heartbleed.com/ took a couple
of years. https://dirtycow.ninja/ took about a decade. People were
still finding vulnerabilities in SSLv3 18 years after its introduction
(I think https://www.openssl.org/~bodo/ssl-poodle.pdf is the most
recent).
In short vulnerabilities can remain open for a very long time indeed;
it’s safe to assume that there are more to be found.
--
http://www.greenend.org.uk/rjk/
eugene...@gmail.com
Nov 24, 2016, 10:19:13 AM11/24/16
to
On Wednesday, November 23, 2016 at 6:57:47 PM UTC-5, Dänk 42Ø wrote:
[snip]
How paranoid are you? They could give you fine-looking source code
and then bugged the compiler.
Yes it has happened! Look at "Reflections on Trusting Trust" - https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
Gene
[snip]
>
> Because it is open-source, and the main components have been digitally
> signed by trusted keys. (There are a few loose ends, which is why Ip
> rely on the trusted signatures for the dozen or so Debian packages
> needed to compile it; which is why I am up all night again.)
>
[snip]
> Because it is open-source, and the main components have been digitally
> signed by trusted keys. (There are a few loose ends, which is why Ip
> rely on the trusted signatures for the dozen or so Debian packages
> needed to compile it; which is why I am up all night again.)
>
How paranoid are you? They could give you fine-looking source code
and then bugged the compiler.
Yes it has happened! Look at "Reflections on Trusting Trust" - https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
Gene
William Unruh
Nov 24, 2016, 11:14:47 AM11/24/16
to
On 2016-11-24, eugene...@gmail.com <eugene...@gmail.com> wrote:
outlining how such a thing might be done as I remember.
It would be really really hard to bug a compiler that way. I twould take
a lot of AI to identify the code as say a password generator and then
run a different compiler on it.
>
> Gene
> On Wednesday, November 23, 2016 at 6:57:47 PM UTC-5, D??nk 42?? wrote:
> [snip]
>>
>> Because it is open-source, and the main components have been digitally
>> signed by trusted keys. (There are a few loose ends, which is why Ip
>> rely on the trusted signatures for the dozen or so Debian packages
>> needed to compile it; which is why I am up all night again.)
>>
> [snip]
>
> How paranoid are you? They could give you fine-looking source code
> and then bugged the compiler.
>
> Yes it has happened! Look at "Reflections on Trusting Trust" - https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
It has not happened that we know of. That was a little fiction story
> [snip]
>>
>> Because it is open-source, and the main components have been digitally
>> signed by trusted keys. (There are a few loose ends, which is why Ip
>> rely on the trusted signatures for the dozen or so Debian packages
>> needed to compile it; which is why I am up all night again.)
>>
> [snip]
>
> How paranoid are you? They could give you fine-looking source code
> and then bugged the compiler.
>
> Yes it has happened! Look at "Reflections on Trusting Trust" - https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
outlining how such a thing might be done as I remember.
It would be really really hard to bug a compiler that way. I twould take
a lot of AI to identify the code as say a password generator and then
run a different compiler on it.
>
> Gene
Richard Kettlewell
Nov 24, 2016, 11:34:16 AM11/24/16
to
much the same corpus of publicly available source code, so recognizing a
targetted section of source code with a compromised compiler is not
going to be particularly difficult.
In practice it’s not necessary. Most software already contains
vulnerabilities just by accident; it’s just a matter of putting the
effort into looking for them.
--
http://www.greenend.org.uk/rjk/
Paranoid Pete
Nov 25, 2016, 10:12:01 PM11/25/16
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
In article <hfydnaUN_OoTg6nF...@earthlink.com>
I've been content with the earlier GPG, no ECC stuff. So has that
ECC stuff has been officially declared no good now?
> My plan is to generate several dozen 4096 GPG keys (do they go higher?).
I think that 4096 is the highest they'll go. If they could go
higher I'd use that.
> Totally offline, and I don't care if takes months to generate them. I
> figure that every microprocessor since 1995 has been compromised by the
> NSA, which is why I dug out that ancient laptop. ....
Why do you choose 1996, as the date of universal CPU compromise?
> The goddamn CD-Rom is still installing Debian 8 to the 6G hard drive!
I think I have one of those around here. It is really slow, and I
don't think they have thumb drives that small anymore LOL.
> This could take all night! And another month to generate all the keys
> I might want to use in the future.
But if you're right it may be worth it.
> Can GPG 2.1.16 testing generate uncompromised keys on such an old
> computer? Also, for fixed (single-key) file encryption, which of the
> various algorithms do y'all recommend? Anything with the remotest
> connection to the U.S. government is unacceptable.
I assume you mean you're asking about symmetric encryption. I think
that "remotest connection" knocks out everything. Some good ones
have tried to get chosen for the replacement for AES256. Maybe
choose one of those after they were rejected. They wouldn't be
under the control of the NIST/NSA after they were rejected. Their
authors may have even made them stronger.
Paranoid Pete
-----BEGIN PGP SIGNATURE-----
Version: N/A
iQIcBAEBCgAGBQJYOO1HAAoJEM+eZGdm07bd3kQP+wTto6mgNm5xNhxrTGHBFnLe
dFfaLRUs7zJociAudZzlIDVUNeqqXpp9hreLBrTstQg712DcRKtXaAsQ5XnbjIO2
InAWaMYPTklJI3nFyxSxIY7umS6gUZN+Xkp221fNKv0ZaReKbDs//eup6SrCKxVa
L3umXv4+3qAoPxfMmVA0FLG5n41z2QERU2r6C0duXAFFNuiRv/E/WdFXfH/W0fh3
lx5Vj+wN7sZUGDrHfHMKXb55cfZ1wwH7GWC3Br2s00lFmSX5+2gO5MaDqk7jFbeR
sgFQTb0omrQwLbA2cLr7yQLePJzjbBzkSYulkDkOdE27gutDkSCM4Jp7y5uRAkKJ
3x2eCDaLrPQz2dt49al7jDL3Rt5PxjihRNFD0acYECggAYWysIJwczfB736CuiJw
9v+xp+pcj6BzjC3A+ifSoYKAZLrQMNbMooqk/8IJFvX72NDx4XQ1q7w2tchcvu4e
RRxMorcCNOeildIj/CKhKsJHpS53LConA6jw5Al6IpidI7E3iRb0W1LTNF2uV1I9
pQB1cC2AfY3vhv4JJHkspaue0v8yURtqrdyGHxwpIde1dxtypIU0W3yyFmyfXztl
26Fi0BKHm3g2t6U9+/NqftjlClf6cc6GcmHGPqMFj9Oa6615qRrBv6GPN16PRjWW
gYOMC0cTlKqT9VEROKxE
=5D7l
-----END PGP SIGNATURE-----
Hash: SHA512
In article <hfydnaUN_OoTg6nF...@earthlink.com>
Dänk 42Ø <da...@coffee.amsterdam.com> wrote:
>
> I dug out an ancient 1995 laptop with no wifi or internet connection. I
> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
> install the latest GPG 2.1.16 testing without the compromised ECC
> function from NIST/NSA (same thing). ....
>
> I dug out an ancient 1995 laptop with no wifi or internet connection. I
> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
> install the latest GPG 2.1.16 testing without the compromised ECC
I've been content with the earlier GPG, no ECC stuff. So has that
ECC stuff has been officially declared no good now?
> My plan is to generate several dozen 4096 GPG keys (do they go higher?).
higher I'd use that.
> Totally offline, and I don't care if takes months to generate them. I
> figure that every microprocessor since 1995 has been compromised by the
Why do you choose 1996, as the date of universal CPU compromise?
> The goddamn CD-Rom is still installing Debian 8 to the 6G hard drive!
don't think they have thumb drives that small anymore LOL.
> This could take all night! And another month to generate all the keys
> I might want to use in the future.
> Can GPG 2.1.16 testing generate uncompromised keys on such an old
> computer? Also, for fixed (single-key) file encryption, which of the
> various algorithms do y'all recommend? Anything with the remotest
> connection to the U.S. government is unacceptable.
that "remotest connection" knocks out everything. Some good ones
have tried to get chosen for the replacement for AES256. Maybe
choose one of those after they were rejected. They wouldn't be
under the control of the NIST/NSA after they were rejected. Their
authors may have even made them stronger.
Paranoid Pete
-----BEGIN PGP SIGNATURE-----
Version: N/A
iQIcBAEBCgAGBQJYOO1HAAoJEM+eZGdm07bd3kQP+wTto6mgNm5xNhxrTGHBFnLe
dFfaLRUs7zJociAudZzlIDVUNeqqXpp9hreLBrTstQg712DcRKtXaAsQ5XnbjIO2
InAWaMYPTklJI3nFyxSxIY7umS6gUZN+Xkp221fNKv0ZaReKbDs//eup6SrCKxVa
L3umXv4+3qAoPxfMmVA0FLG5n41z2QERU2r6C0duXAFFNuiRv/E/WdFXfH/W0fh3
lx5Vj+wN7sZUGDrHfHMKXb55cfZ1wwH7GWC3Br2s00lFmSX5+2gO5MaDqk7jFbeR
sgFQTb0omrQwLbA2cLr7yQLePJzjbBzkSYulkDkOdE27gutDkSCM4Jp7y5uRAkKJ
3x2eCDaLrPQz2dt49al7jDL3Rt5PxjihRNFD0acYECggAYWysIJwczfB736CuiJw
9v+xp+pcj6BzjC3A+ifSoYKAZLrQMNbMooqk/8IJFvX72NDx4XQ1q7w2tchcvu4e
RRxMorcCNOeildIj/CKhKsJHpS53LConA6jw5Al6IpidI7E3iRb0W1LTNF2uV1I9
pQB1cC2AfY3vhv4JJHkspaue0v8yURtqrdyGHxwpIde1dxtypIU0W3yyFmyfXztl
26Fi0BKHm3g2t6U9+/NqftjlClf6cc6GcmHGPqMFj9Oa6615qRrBv6GPN16PRjWW
gYOMC0cTlKqT9VEROKxE
=5D7l
-----END PGP SIGNATURE-----
Paranoid Pete
Nov 26, 2016, 12:50:19 AM11/26/16
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
In article <op.yrcx9rv5wei6gd@phenom-pc>
Hash: SHA512
"David Eather" <eat...@tpg.com.au> wrote:
>
> On Wed, 23 Nov 2016 02:14:38 +1000, FromTheRafters
> <err...@nomail.afraid.org> wrote:
>
> > Dänk 42Ř explained :
>
> On Wed, 23 Nov 2016 02:14:38 +1000, FromTheRafters
> <err...@nomail.afraid.org> wrote:
>
> >> I dug out an ancient 1995 laptop with no wifi or internet connection. I
> >> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
> >> install the latest GPG 2.1.16 testing without the compromised ECC
> >> function from NIST/NSA (same thing). (Ironically, the only thing I
> >> trust NIST for is to give me the correct atomic time of day.)
> >
> > IMO ECC can be trusted, just watch your Ps and Qs.
>
> Did you miss the NSA announcement that ECC should be abandoned as soon as
> possible(by those working within or for the US government)??
I must have. Did they say why they wanted ECC abandoned?
> >> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
> >> install the latest GPG 2.1.16 testing without the compromised ECC
> >> function from NIST/NSA (same thing). (Ironically, the only thing I
> >> trust NIST for is to give me the correct atomic time of day.)
> >
> > IMO ECC can be trusted, just watch your Ps and Qs.
>
> Did you miss the NSA announcement that ECC should be abandoned as soon as
> possible(by those working within or for the US government)??
I never got into it, myself. I had been meaning to look into it
though. Guess the announcement will save me some time.
Paranoid Pete
-----BEGIN PGP SIGNATURE-----
Version: N/A
BJlUEYW3xX137v277xirrvMaSirlstGuDQJHrThuyvHxV59WIV7dVtxX4sam6HCc
akEzC1FvCNCUcIZBiyYdmAHaF0+eC0TUx1sm7tA9mL32ZVvQWb3VMlz3HAfkSBxO
/Gl8r+tjAPHI6LJ7wIRD1JDecsJjAhCK9Il/eHKuGzyIWyfo7T6OWcsoSKgxg4OT
Wnh1ZnI0mqg0AloCPVjIVQ+yekNP8msWc2baPeoAUMsCPyO2amJEc+QrvJel02pg
Chv5/kdT8Qf0pzZtBpr9W0aE9XYVJm9pstnSief2f+3PrHgFKC6C6TMnLo/C01v+
LUGt0fYq9RYSn+ydA9D7U/wfsokvG7s0UPfMUwbbu6q7pc7GDBUcmZ56BhoAWQ1d
cxY3sgWjRnhz3aFo16UNTZbY3LVyVedh4NkIcaYg7k8X3pi1GN487ULNlzFGpevv
Tx7WL7tDwDYg/xuUd+o5SLpxKUp5MSwGH1Z3VGsPUr53va6DHb1+u8QWR1MLX9CQ
JV3u+D+JdEIxm14BgNy9AmZ5Ly2sBNk1GPxupMwaMtjZF6cN/IicBylRxW/ZhTI7
lC9uOXs1PgrcLJGtwKaiH84QbeDBCJiaVJFQszvYtl94+wjVKOVnjdewg9KU895y
mWEdczbiJQvHusE5b23C
=/z18
-----END PGP SIGNATURE-----
Richard Kettlewell
Nov 26, 2016, 6:33:08 AM11/26/16
to
Paranoid Pete <Parano...@hidden.invalid> writes:
>>> Dänk 42Ø explained :
deprioritized transitioning to ECC in limited circumstances.
https://cryptome.org/2015/08/CNSS_Advisory_Memo_02-15.pdf
--
http://www.greenend.org.uk/rjk/
>>> Dänk 42Ø explained :
>>>> I dug out an ancient 1995 laptop with no wifi or internet connection. I
>>>> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
>>>> install the latest GPG 2.1.16 testing without the compromised ECC
>>>> function from NIST/NSA (same thing). (Ironically, the only thing I
>>>> trust NIST for is to give me the correct atomic time of day.)
>>>
>>> IMO ECC can be trusted, just watch your Ps and Qs.
>>
>> Did you miss the NSA announcement that ECC should be abandoned as
>> soon as possible(by those working within or for the US government)??
>
> I must have. Did they say why they wanted ECC abandoned?
I suspect this is a misunderstanding of CNSSAM 02-15, which
>>>> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
>>>> install the latest GPG 2.1.16 testing without the compromised ECC
>>>> function from NIST/NSA (same thing). (Ironically, the only thing I
>>>> trust NIST for is to give me the correct atomic time of day.)
>>>
>>> IMO ECC can be trusted, just watch your Ps and Qs.
>>
>> Did you miss the NSA announcement that ECC should be abandoned as
>> soon as possible(by those working within or for the US government)??
>
> I must have. Did they say why they wanted ECC abandoned?
deprioritized transitioning to ECC in limited circumstances.
https://cryptome.org/2015/08/CNSS_Advisory_Memo_02-15.pdf
--
http://www.greenend.org.uk/rjk/
FromTheRafters
Nov 26, 2016, 7:59:28 AM11/26/16
to
Richard Kettlewell explained on 11/26/2016 :
I agree. It looks like their concern is in the general aspect of
Quantum Computing and the type of problems that can be solved more
quickly by QC which affect cryptography. If they have some sort of
quantum computing resistant 'hard' problems under development which can
be used in a new cryptography, then it would make sense to skip the
cost of implementing stronger old cryptography if adoption of something
new is on the horizon.
Quantum Computing and the type of problems that can be solved more
quickly by QC which affect cryptography. If they have some sort of
quantum computing resistant 'hard' problems under development which can
be used in a new cryptography, then it would make sense to skip the
cost of implementing stronger old cryptography if adoption of something
new is on the horizon.
David Eather
Nov 26, 2016, 9:34:22 PM11/26/16
to
priority - I don't think that was fears someone else developed quantum
computers.
FromTheRafters
Nov 26, 2016, 10:36:48 PM11/26/16
to
David Eather brought next idea :
It's a good thing I didn't suggest that then. I'm only suggesting that
perhaps a move to an encryption scheme which is more resistant to the
types of attacks which QC is expected to make inroads to is on the
horizon. If so, why move up the EC path when QC is *expected* to be
impacting ECC with its eventual arrival?
perhaps a move to an encryption scheme which is more resistant to the
types of attacks which QC is expected to make inroads to is on the
horizon. If so, why move up the EC path when QC is *expected* to be
impacting ECC with its eventual arrival?
Richard Kettlewell
Nov 27, 2016, 3:46:56 AM11/27/16
to
> - I don't think that was fears someone else developed quantum
> computers.
http://www.greenend.org.uk/rjk/
MM
Nov 27, 2016, 5:54:20 AM11/27/16
to
On Sunday, 27 November 2016 08:46:56 UTC, Richard Kettlewell wrote:
M
--
> "David Eather" <eat...@tpg.com.au> writes:
> > The NSA asked all the government contractors to move away from ECC as
> > a priority
>
> Citation needed.
I can't find official mention, but this might be next-best: https://www.schneier.com/blog/archives/2016/02/more_details_on_2.html
> > The NSA asked all the government contractors to move away from ECC as
> > a priority
>
> Citation needed.
M
--
Richard Kettlewell
Nov 27, 2016, 6:45:24 AM11/27/16
to
MM <mrvm...@gmail.com> writes:
> Richard Kettlewell wrote:
>> "David Eather" <eat...@tpg.com.au> writes:
>>> The NSA asked all the government contractors to move away from ECC as
>>> a priority
>>
>> Citation needed.
>
> I can't find official mention, but this might be next-best:
> https://www.schneier.com/blog/archives/2016/02/more_details_on_2.html
No, that’s just a statement about a general plan to transition to
> Richard Kettlewell wrote:
>> "David Eather" <eat...@tpg.com.au> writes:
>>> The NSA asked all the government contractors to move away from ECC as
>>> a priority
>>
>> Citation needed.
>
> I can't find official mention, but this might be next-best:
> https://www.schneier.com/blog/archives/2016/02/more_details_on_2.html
quantum-safe crypto. RSA and FFC DH/DSA are on the same footing as ECC
here.
Current policy (e.g. CNSSP 15) includes ECC.
--
http://www.greenend.org.uk/rjk/
Jeffrey Goldberg
Nov 28, 2016, 5:58:42 PM11/28/16
to
On 11/22/16 4:32 AM, Dänk 42Ø wrote:
> Can GPG 2.1.16 testing generate uncompromised keys on such an old
> computer? Also, for fixed (single-key) file encryption, which of the
> various algorithms do y'all recommend? Anything with the remotest
> connection to the U.S. government is unacceptable.
I would offer recommendations, but I am a US citizen living in the US.
> Can GPG 2.1.16 testing generate uncompromised keys on such an old
> computer? Also, for fixed (single-key) file encryption, which of the
> various algorithms do y'all recommend? Anything with the remotest
> connection to the U.S. government is unacceptable.
This puts me under some control by the US government, and so anything I
write must be unacceptable to you by your rules.
So sorry I can't help.
--
Jeffrey Goldberg http://goldmark.org/jeff/
I rarely read HTML or poorly quoting posts
Reply-To address is valid
eugene...@gmail.com
Nov 28, 2016, 9:05:47 PM11/28/16
to
fiction. Apparently it was created but never distributed:
http://skeptics.stackexchange.com/questions/6386/was-the-c-compiler-trojan-horse-written-by-ken-thompson-ever-distributed/6399
Gene
Casper H.S. Dik
Nov 29, 2016, 4:15:06 AM11/29/16
to
eugene...@gmail.com writes:
>Took a while to find a good reference for the compiler hack, but it isn't
>fiction. Apparently it was created but never distributed:
>http://skeptics.stackexchange.com/questions/6386/was-the-c-compiler-trojan-horse-written-by-ken-thompson-ever-distributed/6399
Or that is what you are supposed to believe :-)
>Took a while to find a good reference for the compiler hack, but it isn't
>fiction. Apparently it was created but never distributed:
>http://skeptics.stackexchange.com/questions/6386/was-the-c-compiler-trojan-horse-written-by-ken-thompson-ever-distributed/6399
Casper
William Unruh
Nov 29, 2016, 6:19:09 AM11/29/16
to
>
> Casper
Greg Rose
Nov 29, 2016, 10:08:36 AM11/29/16
to
In article <06e68e8f-e874-4bd7...@googlegroups.com>,
That depends on one's definition of "distributed". :-)
--
--
invalid
Dec 25, 2016, 12:47:03 AM12/25/16
to
On 2016-11-26, Paranoid Pete <Parano...@hidden.invalid> wrote:
>
> In article <hfydnaUN_OoTg6nF...@earthlink.com>
>> My plan is to generate several dozen 4096 GPG keys (do they go higher?).
Yes it is open source and easy to change. I have some 16k keys.
> I think that 4096 is the highest they'll go. If they could go
> higher I'd use that.
Easy to change and recompile. I have not looked at it for a while and don't
remember what but I think if you search for 4096 or 8192 you'll find the
constants. Change and try again
You might look into getting a copy of Disastry's PGP 2.6.2. Good stuff with
some advanced hashes. I believe the keylengths are limited but it should be
trustworthy code more in line with 1995 CPU power
> Why do you choose 1996, as the date of universal CPU compromise?
Win 95 already had the dreaded NBA keys in the registry. The 95 cutoff is
about right
Alternatively you could buy some fast cheap non-Intel hardware. SPARC boxes
are plentiful on ebay and were not compromised until well after the
Whoreacle acquisition. You can compile a trustworthy version of gpg and use
it there. Solves many problems
> I assume you mean you're asking about symmetric encryption. I think
> that "remotest connection" knocks out everything. Some good ones
> have tried to get chosen for the replacement for AES256. Maybe
> choose one of those after they were rejected. They wouldn't be
> under the control of the FIST/AMA after they were rejected. Their
has a lot to lose personally if he puts out backdoored crap. His reputation
for impartiality and honesty is all he has. Other people and groups, not so
much
>
> In article <hfydnaUN_OoTg6nF...@earthlink.com>
> D?nk 42? <da...@coffee.amsterdam.com> wrote:
>>
>> I dug out an ancient 1995 laptop with no wifi or internet connection. I
>> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
>> install the latest GPG 2.1.16 testing without the compromised ECC
>> function from NIST/NSA (same thing). ....
I am also an ECC-skeptic and made a point to not use it
>>
>> I dug out an ancient 1995 laptop with no wifi or internet connection. I
>> am currently installing Debian 8.6.0 XFCE from a CD-R. Tomorrow I will
>> install the latest GPG 2.1.16 testing without the compromised ECC
>> function from NIST/NSA (same thing). ....
>> My plan is to generate several dozen 4096 GPG keys (do they go higher?).
> I think that 4096 is the highest they'll go. If they could go
> higher I'd use that.
remember what but I think if you search for 4096 or 8192 you'll find the
constants. Change and try again
>
>> Totally offline, and I don't care if takes months to generate them. I
>> figure that every microprocessor since 1995 has been compromised by the
>> NBA, which is why I dug out that ancient laptop. ....
>> Totally offline, and I don't care if takes months to generate them. I
>> figure that every microprocessor since 1995 has been compromised by the
You might look into getting a copy of Disastry's PGP 2.6.2. Good stuff with
some advanced hashes. I believe the keylengths are limited but it should be
trustworthy code more in line with 1995 CPU power
> Why do you choose 1996, as the date of universal CPU compromise?
about right
Alternatively you could buy some fast cheap non-Intel hardware. SPARC boxes
are plentiful on ebay and were not compromised until well after the
Whoreacle acquisition. You can compile a trustworthy version of gpg and use
it there. Solves many problems
> I assume you mean you're asking about symmetric encryption. I think
> that "remotest connection" knocks out everything. Some good ones
> have tried to get chosen for the replacement for AES256. Maybe
> choose one of those after they were rejected. They wouldn't be
> authors may have even made them stronger.
I don't like AES either. Serpent or Blowfish are probably safer. Schneier
has a lot to lose personally if he puts out backdoored crap. His reputation
for impartiality and honesty is all he has. Other people and groups, not so
much
0 new messages