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
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
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
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
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
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
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
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
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
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. :-)
> >
>
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
