On 1112218673 seconds since the Beginning of the UNIX epoch
"ALeine" wrote:
>
>Using mlockall(2) to prevent paging and setrlimit(2) to prevent core
>from being dumped would also be an improvement for both CGD and GBDE.
That's what I just did. :-)
ded contents
of the lock sector into memory which contain all of the information
needed to decrypt the disk. In cmd_nuke(), the malloc is followed
immediately by a memset(3) which could core dump.
--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
it tries
to instantiate memory that does not exist.
All that said, I've fixed the problem and will be submitting a
pullup request for the next NetBSD release.
--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
___
freebsd-ha
rmation in there that could be cross referenced.
The examples abound. Disks are very well structured and so are
the files on them. So, I think that considering that you are
cracking 16KB at a time there will not be terribly many false
positives to find. You will not have to write a lot o
On 1109800339 seconds since the Beginning of the UNIX epoch
"ALeine" wrote:
>
>> Both Lucky Green and David Wagner has nodded vertical on GBDE.
>
>I trust the professional opinions of both Lucky Green and David Wagner
>at least an order of magnitute more th
On 1109809815 seconds since the Beginning of the UNIX epoch
"Poul-Henning Kamp" wrote:
>
>In message <[EMAIL PROTECTED]>, Roland Dowdeswell wr
>i
>tes:
>
>>Let's discuss a simple example and see how it works. Let's walk
>>through a user login,
the sectors individually, ignoring the rest of the
system. If the results of Yarrow are found to be predictable, then
guessing the sector keys becomes much easier. So, there are two
algorithms that will individually make cracking the disk substantially
ea
top---or as in the article NAS/SAN architectures,
where the storage is not nec. coresident with the computer.
--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebs
ially and
obviously false. Or just crack one key-key sector in 2^128, reverse
the MD5 in 2^128 to obtain the salt and get the rest of the disk
in < 2^128, for a grand total of O(2^129). Together these methods
seem to indicate that 2^384 is a little exaggerated.
--
Roland Dowdeswell
eaning to write up but haven't
quite found the time that would knock a few more bits off.
--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
for however long it
takes to break AES-128.) There is no [reasonable] possibility of
recovery.
--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
There is no way to solve the problem, too, because
thttpd cannot know reliably whether it can fork before it tries
to.
I think that we ended up putting in this ``fork-bomb protection''
conditionally with the default of off.
--
Roland Dowdeswell http://www.Imrry
k. This will lead to a situation where fsck may
not be able to recover your file system.
A file system depends on certain assumptions about the underlying
disk device, namely that a single sector write is an atomic operation
in order to accomplish its task. It looks to me from the paper
and the code
13 matches
Mail list logo
