On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander <magnus@hagander.net> wrot=
e:
> On Fri, Jan 27, 2012 at 18:54, Marko Kreen <markokr@gmail.com> wrote:
>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>> <stefan@kaltenbrunner.cc> wrote:
>>> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>>>> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>>>> Yeah, it should be fixed. =A0But note that "random data" is part of
>>>> decrypt() spec - the validation it can do is a joke.
>>>>
>>>> Its more important to do proper checks in encrypt() to avoid invalid
>>>> stored data, but there the recommended modes (CBC, CFB) can work
>>>> with any length data, so even there the impact is low.
>>>
>>> I agree - but in my case the input to those functions is actually coming
>>> from external untrusted systems - so if the data is (completely) invalid
>>> really want to get a proper error message instead of random memory cont=
ent.
>>
>> You *will* get random memory content. =A0If your app is exploitable with
>> invalid data, you *will* get exploited. =A0The decrypt() checks are
>> more for developer convenience than anything more serious.
>
> Hold on. I hope there's some misunderstanding here.
>
> I hope you are you saying that feeding random data to the decrypt
> functions should be expected to return random data out of previously
> free()d areas? Surely you're not?
>
> Obviouly, if you send in invalid data or an invalid key, it will
> decrypt into incorrect data, that goes without saying. But it should
> still be the same block size and not contain random unrelated memory
> blocks, shouldn' it?
Yes, it should not contain unrelated data.
--=20
marko
