gnupg binaries too big? / OpenBSD Moving Towards Signed Packages — Based On D. J. Bernstein Crypto

[Mark Schneider]

Hi,

Is there any possibility to create a minimal version of gnupg?

http://bsd.slashdot.org/story/14/01/19/0124202/openbsd-moving-towards-signed-packages-based-on-d-j-bernstein-crypto
# ---
/"It's official: 'we are moving towards signed packages 
,' says Theo de 
Raadt on the misc@ mailing list. This is shortly after a new utility, 
signify , was committed 
into the base tree. The reason a new utility had to be written in the 
first place  is that gnupg 
is too big to fit on the floppy discs, which are still a supported 
installation medium for OpenBSD. Signatures are based on the Ed25519 
 public-key signature system from D. J. 
Bernstein and co., and his public domain code once again appears 
 in the base tree 
of OpenBSD, only a few weeks after some other DJB inventions made it 
into the nearby OpenSSH 
 
as well."/



Kind regards, Mark

--
m...@it-infrastrukturen.org

http://rsync.it-infrastrukturen.org

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?)

[Mark Schneider]

Am 08.12.2013 19:13, schrieb NdK:

Why is everyone thinking 'BIOS' as backdoorable piece of sw? Why not the
hard disk?
http://spritesmods.com/?art=hddhack

Just another piece to think of when building a secure system...

Excellent article! Thank you.

Writing firmware I meant every piece of code "for / inside" all involved 
hardware components and in particular with their own controllers (eg. 
keyboard, USB ...) and not only the BIOS of the motherboard.


Some backdoors can be hardcoded in  the hardware of controller chips 
(eg. network controller etc).
Sending a special sequence of data to them can turn them in the "debug 
or whatever" mode.


Hacking smartcards is more complicated but possible.

BTW: there is no video at:
http://achtbaan.nikhef.nl/events/OHM/video/d2-t1-13-20130801-2300-hard_disks_more_than_just_block_devices-sprite_tm.m4v

Kind regards, Mark

--
m...@it-infrastrukturen.org

http://rsync.it-infrastrukturen.org


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?)

[Mark Schneider]

Am 08.12.2013 11:51, schrieb Paul R. Ramer:

Peter Lebbing  wrote:

We're debating the risk that a card is backdoored. If there is such a
risk, that
risk still exists if we allow for the possibility that manufacturers
try to do
what you say. They're not mutually exclusive; how come you infer that I
assume
that the manufacturer would not do the opposite?

It was not my intent to make it seem that I had made any insinuations on your 
part.  It was more that I wanted to express an alternate possibility rather 
than the nefarious one that was being discussed.

It seemed that the only scenario involving pressure or coercion on the part of 
the U.S. being discussed was one of compliance by the company rather than a 
range of possibilities.  Events in life do not always happen neatly and 
predictably.  If we are going to discuss outcomes, we need to talk about more 
than one.
Looking backwards (history) if there was a possibility to build in a 
backdoor such one

always had happened and had been exploited.
It applied and still applies for "most" of commercial IT software and 
hardware vendors

and even such OSS projects focused on securiry like openBSD (in the past).

Smart cards are good only for a certain level of privacy to keep rather 
primitive ciriminals away.


As long everyone is not able to audit the source code of firmware or 
operating systems
(in particular closed source software products) there are a lot of other 
possibilities to steal your secrets.


I didn't follow the history of the CryptoStick until now but I would 
like to add my "few cents" somewhere later.


An idea would be not to trust anyone and to create so called linux live 
images yourself.

(saving them on a read-only medium and booting from it into live mode).
Example and some description how to do it:
http://rsync.it-infrastrukturen.org/banque-live/
http://git.it-infrastrukturen.org/banque-live.git

Due to my limited time resources all existing .iso images there are 
currently NOT up to date (8 months old).
It is for me a time intensive challenge to patch gnupg 2.0 or the much 
more interesting 2.1

to support longer keys and create .deb packages with all dependencies.
(like RSA 15k .. even they are not inside "secure" standards  .. from my 
"paranoid" point of view)


A little security is not real security. There always can be backdoors in 
the firmware (BIOS, closed source drivers etc).


Kind regards, Mark

--
m...@it-infrastrukturen.org

http://rsync.it-infrastrukturen.org


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Implementation idea of CURVE25519 for gnupg 2.1

[Mark Schneider]

Hi,

There is GPL 3 based implementation of CURVE25519 called Pretty Curved 
Privacy (pcp1).

http://www.daemon.de/PrettyCurvedPrivacy

What do you think about using parts of the ppc1 source code to implement 
such functionality into gnupg 2.1?

http://www.daemon.de/idisk/Apps/PrettyCurvedPrivacy/pretty-curved-privacy-0.1.4.tag.gz

Myself I like this "SCII Case Demo" video how to use this utility:
http://asciinema.org/a/6135

Short description (from the website):
# ---
Pretty Curved Privacy (pcp1) is a commandline utility which can be used 
to encrypt files. pcp1 uses eliptc curve cryptography for encryption 
(CURVE25519 by Dan J. Bernstein). While CURVE25519 is no worldwide 
accepted standard it hasn't been compromised by the NSA - which might be 
better, depending on your point of view.


Caution: since CURVE25519 is no accepted standard, pcp1 has to be 
considered as experimental software. In fact, I wrote it just to learn 
about the curve and see how it works.


Beside some differences it works like GNUPG. So, if you already know how 
to use gpg, you'll feel almost home.

# ---

Kind regards, Mark

--
m...@it-infrastrukturen.org

http://rsync.it-infrastrukturen.org


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Threema. / don't trust closed source software

[Mark Schneider]

Am 10.11.2013 02:46, schrieb Robert J. Hansen:

Looking over their site briefly I was unable to find a link for source code. As 
a result, I think very little of it. I don't think it's wise to trust unknown 
third-party binaries that don't provide source.
It is commercial iOS and Androif application without source code and 
evenn such important details like the used encryption.


Don't trust closed source software products!

regards, Mark

--
m...@it-infrastrukturen.org

http://rsync.it-infrastrukturen.org
http://git.it-infrastrukturen.org


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

[Mark Schneider]

Am 27.10.2013 20:41, schrieb Werner Koch:

On Sun, 27 Oct 2013 17:47, gn...@oneiroi.net said:


Numbers please? Or are you talking about personal/subjective impressions?

What about you running some benchmarks for us?  Let's say: a 4k RSA key
signed by 90 other 4k RSA keys, 8 2k RSA keys, and one 8k RSA key.  For
security reasons key signature chaching has been disabled
(--no-sig-cache) because you obviously can't accept that in this high
security theater.  Run encryption+signature tests for 2 recipienst out
of the set of these 100 keys.

Compare that do a set of 2k keys with only one 4k key.

Run these tests again on an average netbook.
Are there formal reasons why the max length of the RSA key is limited in 
gnupg[2] linux packages to 4096 Bits only?


One thing are the available performance and sane defaults, the other one 
the available security.

(without patching the source code and rebuilding packages)

The max length of the key does not have anything to do with zero-exploits.
When collecting tons of data there is only this data .. nothing else to 
break in.


I don't trus NIST myself and I guess most of you know why.
The question is if similar institution in Europe, Asia, Africa or 
Australia cen be trusted more.



Shalom-Salam,

Werner


p.s.
Once I did tests with off-the self smartcards.  Signing a mail with 1k
RSA key using these smartcards took more than one second - it was barely
unusable for every days mail processing.  Only when we moved to our own
smartcards (the old AVR based 1k RSA keys) using a smartcards was
actually usable (<100ms).  You don't want to wait 10 seconds to decrypt
a thread of 10 mails just to notice that it was only CCed office
chitchat.


Kind regards, Mark

--
m...@it-infrastrukturen.org

http://rsync.it-infrastrukturen.org


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users