On Tue, 24 Jul 2018 13:57, hanno(_at_)hboeck(_dot_)de said:
This does not seem to reflect the lessons to be learned from efail.
Sorry, that remark does not make any sense. We have explained in detail
why it was bot possible to hard fail on MDC and we can do this only know
with the “support” of EFFail. The major points of Efail are bad
integration and in-correct use of tools. You can shoot into your foot
even with simple standard toools like cat.
I think it is very important to hard-restrict the chunk size to a
manageable size, also manageable for small devices (i.e. even 128 mb is
far too much), so that authenticating before any output is produced is
If you have a small device you don't have a way to store large amounts
of data and thus even a lower limit does not make sense because it won't
be reached. The only option an implementation hast to trow up the hands
and say : message too large to decrypt. That is even before checking the
message.
I.e. I propose to change it to a MUST NOT and to have a smaller
maximum chunk size (I think something in the kilobyte range is a good
A kilobyte is - sorry I have no other words for this - stupid. We are
talking about gigs and not a single memory page. I think 128 MiB is a
good compromise - in particular for small device which suffer more for
the expensive steps of the chunk processing. For large amounts of data
that is acceptable high.
Salam-Shalom,
Werner
--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpITKBGKK3WD.pgp
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp