Re: gpg > addphoto

[Stefan Claas]

On Fri, 11 Jan 2019 23:49:02 +0100, Stefan Claas wrote:
> On Wed, 9 Jan 2019 18:06:52 +0100, Stefan Claas wrote:
>  
> > O.k. i did a quick check on github for proper tools and found this
> > very interesting tool, written in Golang.
> > 
> > https://github.com/umahmood/steg  
> 
> Just had the time to test this very nice little tool with GnuPG.
> 
> I prepared an image 800x571 pixels 72dpi and embedded an mp3
> message, created with the macOS say command.
> 
> Everything works as expected. One only needs to use then:
> 
> gpg --list-keys --list-options show-photo 359A1872F120F7E7
> 
> so that preview from macOS displays the image for saving (with
> standard settings).
> 
> Very nice and easy workflow and the resulting key is only 61KB in size.
> 
> If someone like to look at the key:
> 
> https://pgp.circl.lu/pks/lookup?op=get=0x359A1872F120F7E7

I have quickly compiled steg for 26 OS platforms, so that everybody can
test it out. ;-)



Regards
Stefan


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

Re: gpg > addphoto

[Dirk Gottschalk via Gnupg-users]

Hi Stefan.

Am Donnerstag, den 10.01.2019, 19:33 +0100 schrieb Stefan Claas:
> On Thu, 10 Jan 2019 18:38:36 +0100, 
> dirk.gottschalk1...@googlemail.com wrote:

> Hi Dirk,

> > Am Donnerstag, den 10.01.2019, 16:23 +0100 schrieb Stefan Claas:
> > And this prevents also prevents an unintended DoS which means a
> > very big key by mistake. It's okay to allow the generation of
> > everything a user wants, especially in open source software where
> > everybody can change the values. A hard limit would make no sense
> > at all.

> Just wondering, have you ever used other (more modern) open source
> crypto software, which have hard limits and still get's the job done?

Yes, there sure is, but, as long as the tool is open source and anybody
who wants to change the limit to his own, such limits are useless.

Regarding to this, the Parameter is applied to avoid reading  larger
Packets than 16M for importing and so on, on the client side. So, if a
'bad guy' alters his version of GPG in a way to create such abusive
keys, the other users with an unaltered version should not get into
trouble with such a key.

Okay, it's quite possible to set this read limit down to, let's say,
8M, but I think 16M is a good limit to avoid hanging and other side
effects with a way to large key.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



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

Re: gpg > addphoto

[Michael A. Yetto]

On Wed, 09 Jan 2019 23:40:02 -0900
justina colmena via Gnupg-users  writes, and
having writ moves on:

>It's a peculiar problem with which law enforcement is of little or no
>assistance. There's a gun and a badge and a gang of dicks with
>flashlights all over town, and a heavy-breathing warrant to bust your
>door in on that stuff. Neither the law enforcement credentials nor the
>color of law excuse the base human desire of cops to indulge their own
>flesh. 

>

I think you are responding to your own view of the world here and not
to the tread or anything pertaining to GNUPG. 

I for one would appreciate it if such vitriol as this is left in a more
appropriate venue than this mailing list.

Choosing such a venue is left as an exercise for the reader.

Mike Yetto
-- 
"It's the job that's never started as takes longest to finish."
 - Samwise Gamgee

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

Re: gpg > addphoto

[Stefan Claas]

On Wed, 9 Jan 2019 18:06:52 +0100, Stefan Claas wrote:
 
> O.k. i did a quick check on github for proper tools and found this
> very interesting tool, written in Golang.
> 
> https://github.com/umahmood/steg

Just had the time to test this very nice little tool with GnuPG.

I prepared an image 800x571 pixels 72dpi and embedded an mp3
message, created with the macOS say command.

Everything works as expected. One only needs to use then:

gpg --list-keys --list-options show-photo 359A1872F120F7E7

so that preview from macOS displays the image for saving (with
standard settings).

Very nice and easy workflow and the resulting key is only 61KB in size.

If someone like to look at the key:

https://pgp.circl.lu/pks/lookup?op=get=0x359A1872F120F7E7

Regards
Stefan

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

Re: gpg > addphoto

[justina colmena via Gnupg-users]

On January 8, 2019 11:23:40 AM AKST, dirk1980ac via Gnupg-users 
 wrote:
>Hello.
>
>Am Dienstag, den 08.01.2019, 20:16 +0100 schrieb Stefan Claas:
>
>> Yes, agreed! However, as it currently is there is no need for bad
>> actors because people have plenty of image space in a key.
>
>Uh, I think you have found a new place where the guys can hide their
>porn collections so there wifes don't find it.
>
>Sorry, could not resist.
>
>Regards,
>Dirk


It's a peculiar problem with which law enforcement is of little or no 
assistance. There's a gun and a badge and a gang of dicks with flashlights all 
over town, and a heavy-breathing warrant to bust your door in on that stuff. 
Neither the law enforcement credentials nor the color of law excuse the base 
human desire of cops to indulge their own flesh.

A related problem is "image phreaking." People make a game of digitally 
altering images and obscuring their source. Others make a game of deobfuscating 
the images and tracking them down. There is a very close-knit community of this 
sort of thing among disreputable hangers-on to Interpol, Europol, US FBI, 
Russian FSB, etc.

Several times I have been forced to permanently dissociate myself from all 
images and photos ever to have been associated with me, whether photos I have 
taken myself or which were found on my computer. Those people were hunting me, 
and they were led astray by their false assumptions, because *I* usually assume 
when foreign cops are hunting me that they are hunting to kill, and not to 
bring criminal or civil charges in court.

Wherever there is a photo or image of any sort, cops as well as a certain 
low-class security apparatchik always _assume_ an unhealthy obsession or morbid 
desire to memorialize something or someone. I mean, if you're not a 
professional photographer, you are _assumed_ to be trespassing on their 
intellectual property in some way or another, however they can twist it around 
in court to make it appear so. It's all part and parcel of the artsy-fartsy 
red-light district with the FBI warnings on all the Hollywood movies, actresses 
accusing male fans of stalking, etc.

So digital photos and images become a cop-calling feminists' emotional space 
where men in general and less privileged women are prohibited by law, but 
professional necktied gentlemen are perfectly welcome.
-- 
Una Milicia bien regulada, estando necesaria a la seguridad de un Estado libre, 
el derecho del pueblo de tener y de portar Armas, no será infringido.

https://www.colmena.biz/~justina/

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

Re: gpg > addphoto

[Stefan Claas]

On Thu, 10 Jan 2019 18:38:36 +0100, dirk.gottschalk1...@googlemail.com wrote:

Hi Dirk,

> Am Donnerstag, den 10.01.2019, 16:23 +0100 schrieb Stefan Claas:

> And this prevents also prevents an unintended DoS which means a very
> big key by mistake. It's okay to allow the generation of everything a
> user wants, especially in open source software where everybody can
> change the values. A hard limit would make no sense at all.

Just wondering, have you ever used other (more modern) open source
crypto software, which have hard limits and still get's the job done?

Regards
Stefan

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

Re: gpg > addphoto

[Peter Lebbing]

On 10/01/2019 15:56, Stefan Claas wrote:
> Have you or anybody else seen such a large and legitimate attribute
> packet, also one from before 2014?

That would be rather surprising as usually such limits are chosen to be
quite conservative, i.e., way above what is legitimately used. That
would thus mean that there are no such large legitimate attributes.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg > addphoto

[dirk1980ac via Gnupg-users]

Hello.

Am Donnerstag, den 10.01.2019, 16:23 +0100 schrieb Stefan Claas:

> > It's part of GNU philosophy to not implement unnecessary
> > hard limits in software but one good reason to impose limits
> > is to prevent denial of service conditions. 

> What i really don't get with this DoS stuff is when one uses with
> friends etc. the regular version of GnuPG / PGP and obtains the
> keys from friends, checks the fingerprint why should one worry?
> Sure, if i customize the source code I can do such stuff to other
> keys on SKS key servers, but then people can still ask their friends
> and say "hi there seems to be something wrong with your key, can you
> mail me please a copy".

DoS does not necessarily mean crashing the system. A "hanging" process
or a process that takes much more time as necessary is also a DoS.

Crashing a system is only the hardest variant.

And this prevents also prevents an unintended DoS which means a very
big key by mistake. It's okay to allow the generation of everything a
user wants, especially in open source software where everybody can
change the values. A hard limit would make no sense at all.


> Or are there cases when messages are in transient and can those
> be quickly modified, so that GnuPG crashes (your system)?

As said, it's not necessarily a crash, but GPOG takung two hours to
process a key which has gigabytes, just for example, could be
considered a DOS. ^^

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg > addphoto

[Stefan Claas]

On Thu, 10 Jan 2019 09:41:59 +1100, gn...@raf.org wrote:
> Stefan Claas wrote:
> 
> > I only wanted to know why such a large image size in the first
> > place was chosen, when GnuPG suggest a much much smaller
> > size. :-)  
> 
> I'd guess that it's not about image size. It's a
> maximum packet size. 

Sorry, yes you are right it is the maximum packet size,
but as understood used for images only. Or are there
any more attribute packets like No. 1? (i have to check
the draft, i guess.)

>Things other than images have to
> go in there as well (although an image would no doubt
> usually take up most of the space). 

There are different packets for each purpose, as understood.

> It's part of GNU philosophy to not implement unnecessary
> hard limits in software but one good reason to impose limits
> is to prevent denial of service conditions. 

What i really don't get with this DoS stuff is when one uses with
friends etc. the regular version of GnuPG / PGP and obtains the
keys from friends, checks the fingerprint why should one worry?
Sure, if i customize the source code I can do such stuff to other keys
on SKS key servers, but then people can still ask their friends and
say "hi there seems to be something wrong with your key, can you
mail me please a copy".

Or are there cases when messages are in transient and can those
be quickly modified, so that GnuPG crashes (your system)?

Regards
Stefan

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

Re: gpg > addphoto

[Stefan Claas]

On Wed, 9 Jan 2019 23:13:33 +, Damien Goutte-Gattat wrote:
> On Wed, Jan 09, 2019 at 11:29:06PM +0100, dirk1980ac via Gnupg-users wrote:
> > > I only wanted to know why such a large image size in the first
> > > place was chosen, when GnuPG suggest a much much smaller
> > > size. :-)  
> > 
> > I think the 16M are from times, where RAM was nbot measured in GB.  
> 
> Not quite. If you look at the code’s history, you’ll find that the 16MB
> limit is actually from 2014 [1]. There was no limitation on the size of
> user attribute packets before that.

Thanks for the info!

> It is wise to be careful when you abruptly introduce a limitation that
> did not exist before; 16MB was chosen because it is big enough to avoid
> breaking any existing key with a legitimate user attribute packet, while
> still preventing DoS attempts with deliberately oversized packets.

Have you or anybody else seen such a large and legitimate attribute
packet, also one from before 2014? I really would like to see such a
key to get a better understanding.
 
Regards
Stefan

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

Re: gpg > addphoto

[Damien Goutte-Gattat via Gnupg-users]

On Wed, Jan 09, 2019 at 11:29:06PM +0100, dirk1980ac via Gnupg-users wrote:
> > I only wanted to know why such a large image size in the first
> > place was chosen, when GnuPG suggest a much much smaller
> > size. :-)
> 
> I think the 16M are from times, where RAM was nbot measured in GB.

Not quite. If you look at the code’s history, you’ll find that the 16MB
limit is actually from 2014 [1]. There was no limitation on the size of
user attribute packets before that.

It is wise to be careful when you abruptly introduce a limitation that
did not exist before; 16MB was chosen because it is big enough to avoid
breaking any existing key with a legitimate user attribute packet, while
still preventing DoS attempts with deliberately oversized packets.

Of note, the OpenPGP RFC does allow arbitrary large attribute packets,
which means that strictly speaking, GnuPG is already "wrong" to reject a
packet larger than 16MB.


- Damien


[1] https://dev.gnupg.org/rGbab9cdd971f35ff47e153c00034c95e7ffeaa09a


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

Re: gpg > addphoto

[gnupg]

Stefan Claas wrote:

> I only wanted to know why such a large image size in the first
> place was chosen, when GnuPG suggest a much much smaller
> size. :-)

I'd guess that it's not about image size. It's a
maximum packet size. Things other than images have to
go in there as well (although an image would no doubt
usually take up most of the space). It's part of GNU
philosophy to not implement unnecessary hard limits in
software but one good reason to impose limits is to
prevent denial of service conditions. Perhaps a 16MB
packet size limit was chosen because it would be more
than enough to support keys with a huge number of
signatures, and an image, without causing problems for
users, and without permitting a denial of service
condition. 16MB isn't that much RAM these days. But I
am just guessing. I hope it's not to support hi-res
iris scans, voice prints and compressed DNA. :-)

cheers,
raf


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

Re: gpg > addphoto

[dirk1980ac via Gnupg-users]

Hello Stefan.

Am Mittwoch, den 09.01.2019, 22:50 +0100 schrieb Stefan Claas:
> On Wed, 09 Jan 2019 22:25:21 +0100, 
> dirk.gottschalk1...@googlemail.com wrote:
> 
> Hi Dirk,
> 
> > But, this is more a Problem of SKS. When SKS accepts such keys,
> > it's
> > not GPG's fault.

> Forget SKS for a moment, i send you, or distribute, such a key via
> other mediums and your GnuPG will accept it. :-D

As long, as the size of the picture doesn't exceed 16M, it surely will
be accepted. But this should not take a long time, 16M is nothing, so
there is no Problem with this. Nobody says it has to be prevented.
Sure, GPG can be "abused" in many ways. I also do this by using it for
a purpose it was not invented for. This is not an evil functionality.
If dome people like to put HiRes photos or other pictures in their UID,
for whatever purpose, so it is not an evil thing. Distributing a key
via email is no problem in this case and SKS, WKS and others should
oinly prevent storing those key for storage and sanity reasons.


> I only wanted to know why such a large image size in the first
> place was chosen, when GnuPG suggest a much much smaller
> size. :-)

I think the 16M are from times, where RAM was nbot measured in GB. In
this case it was to avoid long package computation times because the
RAM was smaller than 1GB. They had to choose a limit to avoid DDoS
attacks to GPG on a users computer. There was no intention to limit the
size of the photo because nobody thought about this at the moment of
decision.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg > addphoto

[Stefan Claas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 09 Jan 2019 22:25:21 +0100, dirk.gottschalk1...@googlemail.com wrote:

Hi Dirk,

> But, this is more a Problem of SKS. When SKS accepts such keys, it's
> not GPG's fault.

Forget SKS for a moment, i send you, or distribute, such a key via other
mediums and your GnuPG will accept it. :-D

I am also not complaining or suggesting here something.

I only wanted to know why such a large image size in the first
place was chosen, when GnuPG suggest a much much smaller
size. :-)

Regards
Stefan





-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQTsFcZEw1lI/LR+FYmaI04LDh8f6AUCXDZsmQAKCRCaI04LDh8f
6A9AAQCxUMdjYFbVYfEXyVkpCbT/UDeUDO7ZSD7I0lNBihVvFQD+Kj6T55Du6YAj
/rFZ1awzTJSuIER1M8XC1peazzBLbgk=
=TzJh
-END PGP SIGNATURE-
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg > addphoto

[dirk1980ac via Gnupg-users]

Hi Stefan.

Am Mittwoch, den 09.01.2019, 18:06 +0100 schrieb Stefan Claas:
> On Tue, 8 Jan 2019 20:16:59 +0100, Stefan Claas wrote:

[...]

> The provided Chief Wiggum image contains a 2 seconds .mp4 movie
> clip. Pretty awesome imho! So this means that one can hide in a PGP
> key movies and other files too, hidden in jpeg images and distribute
> it securely via SKS...

But, this is more a Problem of SKS. When SKS accepts such keys, it's
not GPG's fault.

Anyways, anybody can generate anything he wants witrh GPG. Such
restriction would NOT have any effects, because the key generation is
done by the users GPG. Anybody can change the source code of GPG in any
way and generate everything. Restictions at the end is senseless in
open source world. Thje Servers are controlled by their owners so it is
in their  hands, what can be distributed.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part


smime.p7s
Description: S/MIME cryptographic signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg > addphoto

[Stefan Claas]

On Tue, 8 Jan 2019 20:16:59 +0100, Stefan Claas wrote:

> Since this is an interesting subject, i believe, i may check out how much
> payload can be put in such large jpeg images, just out of of interest
> and i may, if time allows, try to get hold of a complete key server dump
> to try to see if i can find something interesting.

O.k. i did a quick check on github for proper tools and found this
very interesting tool, written in Golang.

https://github.com/umahmood/steg

The provided Chief Wiggum image contains a 2 seconds .mp4 movie
clip. Pretty awesome imho! So this means that one can hide in a PGP
key movies and other files too, hidden in jpeg images and distribute
it securely via SKS...

Regards
Stefan

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

Re: gpg > addphoto

[dirk1980ac via Gnupg-users]

Hello.

Am Dienstag, den 08.01.2019, 20:16 +0100 schrieb Stefan Claas:

> Yes, agreed! However, as it currently is there is no need for bad
> actors because people have plenty of image space in a key.

Uh, I think you have found a new place where the guys can hide their
porn collections so there wifes don't find it.

Sorry, could not resist.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



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

Re: gpg > addphoto

[Stefan Claas]

On Tue, 8 Jan 2019 18:50:12 +0100, Peter Lebbing wrote:
Hi Peter,

[snip]

> I hope I did a good job of explaining my meaning this time around.

Yes, i think you did, even if i see things a bit different. But no worries! :-)

Since this is an interesting subject, i believe, i may check out how much
payload can be put in such large jpeg images, just out of of interest
and i may, if time allows, try to get hold of a complete key server dump
to try to see if i can find something interesting.

> But I'd like to tack on even more thoughts :-). Because finally, what
> GnuPG enforces is again something different from what the keyserver
> network enforces. If you're worried about big images or other data being
> uploaded to the keyservers, the place to fix that would be the
> keyservers, not GnuPG, because a bad actor could just change their own
> GnuPG. But they can't change the code running in the public keyserver
> network other than by running their own keyserver.

Yes, agreed! However, as it currently is there is no need for bad actors
because people have plenty of image space in a key.

Regards
Stefan

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

Re: gpg > addphoto

[Peter Lebbing]

Hi Stefan,

On 08/01/2019 17:39, Stefan Claas wrote:
> To be honest i don't understand why this was implemented this way in
> the first place

I'm just guessing, I don't know for sure. But since it seems you're
unclear about what I meant, I'm trying to explain that.

I don't think this implementation is meant to restrict users in creating
image attributes at all. It's not meant as some means to stop a user
from creating a mega-large image. So you're coming at it from the wrong
direction when you say "isn't this a bit too much to allow".

Rather, it's meant as a means to prevent *reading* such a large image.
With all software, but with crypto even more, you need to build in
defenses against people trying to create a mess for others.

So suppose someone created a public key containing some mega-large
image, or corrupting a public key to contain nonsense data. In this
case, when you import this key and your GnuPG is reading this data it
needs to have some safeguards against malfunctioning. You ask why it was
implemented this way. The reasoning is: nobody bona fide would ever
create an (image) attribute larger than 16 MiB. In fact, it would be
much less, but we're being conservative and saying: well, no matter the
circumstances, 16 MiB is certainly ridiculous. So if GnuPG ever
encounters an attribute larger than 16 MiB, it should just stop and
display an error instead of trying to continue. Because clearly
something fishy is going on. A real attribute will always be much
smaller. That's a reason to halt and give up.

So, yes, 16 MiB is ridiculous. That's the point. It's a test to see
whether we are doing something that we're supposed to be doing, or
whether we're looking at something ridiculous.

So when you say "Shouldn't users be forced to limit themselves to
something much smaller?", that's simply a different subject as I
understand it. This 16 MiB has nothing to do with that, it's a different
mechanism.

I hope I did a good job of explaining my meaning this time around.

But I'd like to tack on even more thoughts :-). Because finally, what
GnuPG enforces is again something different from what the keyserver
network enforces. If you're worried about big images or other data being
uploaded to the keyservers, the place to fix that would be the
keyservers, not GnuPG, because a bad actor could just change their own
GnuPG. But they can't change the code running in the public keyserver
network other than by running their own keyserver.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg > addphoto

[Stefan Claas]

On Tue, 08 Jan 2019 11:12:41 -0500, Daniel Kahn Gillmor wrote:
> On Tue 2019-01-08 15:55:30 +0100, Stefan Claas wrote:
> > it seems a bit to much if you look at avatars, profile images
> > etc. on social media sites and other places. The images there are always
> > reasonably in size when displayed and do not offer such large image size for
> > usage, IIRC.  
> 
> I think you're recommending making a change to that default value.

Good question! I think a recommendation is already to late, because
like Peter said one can change the values. To be honest i don't
understand why this was implemented this way in the first place,
but it should be not my business i guess and people might use
it as a replacement for Yakamo K's image uploader to SKS, because
GnuPG makes it convenient to view then such images.

> Do you have a new default value that you want to propose for future
> versions of GnuPG?

GnuPG itself suggests an image size of 240x288 pixels when doing so.
Maybe slightly larger would be fine too.
 
> Have you tried reducing it to your new proposed default value and
> experimented with it, to let us know what it does to, say, photos larger
> than that value already stored in your keyring?

No.
 
> have you tried looking at statistics of what sizes of images are present
> in the public keyserver dumps?

Not yet, but it should be interesting to parse a dump.

> those would all be reasonable next steps if you want to present a
> convincing case for action here.

I did not ask for action here, even if it sounded like that. I was
curious to know why such a large size was implemented.

Regards
Stefan

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

Re: gpg > addphoto

[Daniel Kahn Gillmor]

On Tue 2019-01-08 15:55:30 +0100, Stefan Claas wrote:
> it seems a bit to much if you look at avatars, profile images
> etc. on social media sites and other places. The images there are always
> reasonably in size when displayed and do not offer such large image size for
> usage, IIRC.

I think you're recommending making a change to that default value.

Do you have a new default value that you want to propose for future
versions of GnuPG?

Have you tried reducing it to your new proposed default value and
experimented with it, to let us know what it does to, say, photos larger
than that value already stored in your keyring?

have you tried looking at statistics of what sizes of images are present
in the public keyserver dumps?

those would all be reasonable next steps if you want to present a
convincing case for action here.

regards,

   --dkg


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

Re: gpg > addphoto

[Peter Lebbing]

Hi Stefan,

On 08/01/2019 15:55, Stefan Claas wrote:
> Correct, but still it seems a bit to much

Which is why I think this is not intended as a restriction to the users,
but a restriction for DoS.

Usually people here complain GnuPG doesn't allow for their use case,
it's refreshing to read an opposite complaint ;-).

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg > addphoto

[Stefan Claas]

On Tue, 8 Jan 2019 14:32:21 +0100, Peter Lebbing wrote:

Hi Peter,

> Suppose --edit-key restricted you in some way. This is free software.
> You just remove the restriction and recompile. Just like some people
> enjoy making insanely large RSA keys with GnuPG: they just remove the
> limit and recompile. So restricting --edit-key does not prevent you from
> bad actors.

Correct, but still it seems a bit to much if you look at avatars, profile images
etc. on social media sites and other places. The images there are always
reasonably in size when displayed and do not offer such large image size for
usage, IIRC.

Regards
Stefan

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

Re: gpg > addphoto

[Peter Lebbing]

Hello Stefan,

On 08/01/2019 14:21, Stefan Claas wrote:
> I must admit i don't understand the DoS aspect in this regard

I hadn't looked closely, but since this is MAX_..._LENGTH in
parse-packet.c, I assumed this is a cutoff while parsing packets. So if
GnuPG encounters a packet that declares it is more than 16 MiB in size,
instead of trying to gobble up and interpret and output all this data,
which could lead to DoS (memory exhaustion, disk space exhaustion, long
running time), GnuPG will just error out. So if GnuPG is ever fed
crafted data that tries to DoS GnuPG, it will simply refuse to process
it.

So I assumed this didn't have anything to do with restricting what you
can do with your own GnuPG, but what others can do onto your GnuPG.

Suppose --edit-key restricted you in some way. This is free software.
You just remove the restriction and recompile. Just like some people
enjoy making insanely large RSA keys with GnuPG: they just remove the
limit and recompile. So restricting --edit-key does not prevent you from
bad actors.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg > addphoto

[Stefan Claas]

On Tue, 8 Jan 2019 12:19:53 +0100, Peter Lebbing wrote:
> On 08/01/2019 10:52, Stefan Claas wrote:
> > #define MAX_ATTR_PACKET_LENGTH( 16 * 1024*1024)
> > [...]
> > 
> > Was this large image size requested so that people
> > in crypto circles can hide stuff in images etc. and then
> > use key servers as secret distribution medium?  
> 
> Well, changing this number to something smaller would do nothing to
> prevent this. It's probably just a generous upper limit to prevent a DoS
> on GnuPG. What keyservers accept is not influenced by GnuPG.

I must admit i don't understand the DoS aspect in this regard, in case
a key would only be allowed to a have the suggested* max image size.
Larger sizes could be refused by GnuPG, when editing a key.

*240x288 or slightly bigger.

Regards
Stefan

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

Re: gpg > addphoto

[Peter Lebbing]

On 08/01/2019 10:52, Stefan Claas wrote:
> #define MAX_ATTR_PACKET_LENGTH( 16 * 1024*1024)
> [...]
> 
> Was this large image size requested so that people
> in crypto circles can hide stuff in images etc. and then
> use key servers as secret distribution medium?

Well, changing this number to something smaller would do nothing to
prevent this. It's probably just a generous upper limit to prevent a DoS
on GnuPG. What keyservers accept is not influenced by GnuPG.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg > addphoto

[Stefan Claas]

Hi Werner and all,

may i ask who had the brilliant idea to allow super large photos
in OpenPGP keys?

I ask, because when one likes to add a photo GnuPG recommends
the size of 240x288 Pixels, which is a good choice.

However when looking at parse-packet.c it says at line 44:

#define MAX_ATTR_PACKET_LENGTH( 16 * 1024*1024)

Isn't this not a bit to much? I mean if i am right those
numbers mean 16MB for me.

To test this out i created a 24bit color gradient image
8000x8000 pixels in size and GnuPG says:

[ unbekannt ] (2)  [jpeg image of size 3889016] so
only little bit lesser than 4MB.

Was this large image size requested so that people
in crypto circles can hide stuff in images etc. and then
use key servers as secret distribution medium?

Just curious, because otherwise it would not make to
much sense to me.

Regards
Stefan

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