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 tim
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 whi
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 800x
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 a
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
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 si
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 quit
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
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 mom
-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 oth
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 i
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 wi
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
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 implementati
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
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
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 oppo
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 reco
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
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 s
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 s
26 matches
Mail list logo
