Re: (eternity) Eternity as a secure filesystem/backup medium

[Ryan Lackey <rdl@mit.edu>]

-----BEGIN PGP SIGNED MESSAGE-----


> Since documents placed on eternity by specification last forever (assuming,
> of course, that
> eternity will too) and assuming that computational power and cryptanalysis
> will always
> get better (say for arguments sake that moore's law continues to be held) -
> doesn't that
> mean that it will be feasible (in time) to break all eternity documents? :)

Documents by specification last only as long as someone is willing to pay
to keep them up.  This is not necessarily forever.  Once your DBC escrow
"account" runs out, the data is worthless -- someone could then choose to
store it on their own, and potentially charge others for this in
a recursive model, but there is no reason why a piece of data must
remain in Eternity forever if no one cares enough about it to pay to
have it stored.
> 
> Of course "in time" may very well be a very long (or astronomical) time,
> but dependent on the crypto
> used who knows what rate "feasible" breaking of a particular algorithm
> might progress at, say
> in d(key length)/d(year)? Can we assume that using Moore's law this is at
> least 1 bit every
> 18 months for symmetric crypto? Perhaps we might see this relationship
> through the RSA challenges
> over time.

I am designing Eternity DDS with IDEA/3DES/Blowfish level private-key
crypto and an equivalent level of DH/RSA public key crypto.  These will
be strong (provided back door attacks, fundamental breakthroughs in
cryptography, etc. are not made...a bet I'm forced to make, even though
I don't like it) well into the future.  How far?  I think unless
Quantum Cryptanalysis becomes a reality, the underlying hard problems
will not be solved through anything but a fundamental change in mathematics.
As Prof. Micali said, "Gauss (Karl Friedrich Gauss, the reknowned
mathematician/physicist/general smart guy) worked on these problems.  The test 
of whether a problem is sufficiently hard to be a basis for a cryptosystem
is if Gauss tried to solve it and failed." or something similar.
> 
> [If Wiener's $1m DES machine in '93 took 7 hours, in today's technology $1m
> in 1998 dollars should
> be able to do this in less than 100 minutes, shouldn't it?]

I don't think anyone would argue that 56bit is secure enough for anything
but ephermeal channel authentication.  I'd make the same argument for 64bit --
if you had a purpose-built machine with an intelligent key distribution
system, a well nigh unlimited budget (read: US Military), and PE's which
contained either ultrahigh performance GaAs logic or massively parallel
on a single chip silicon logic, you could probably brute force a 64bit
algorithm.

Do the math, though, for 128bit.  There are traditional analyses which include
the amount of silicon on the earth, the number of atoms in the universe,
etc.  The general consensus is that traditional techniques are not feasible
for brute forcing 128bit ciphers before the heat death of the universe.
> 
> Since documents cannot be retracted or re-encrypted you really have to
> assume that someday they
> will be broken. This really turns the notion of what crypto to use for
> encrypting eternity documents
> into an upfront question of "how long do I want this information to be
> secure?". 20 years? 50 years?
> 100 years?
> 
> matt

Actually, Eternity is no different than emailing a file, given a SIGINT
capability at the attacker which allows all internet traffic to be monitored.
If the data is still relevant and worth breaking in 50 years, they could
just intercept the encrypted email, store it in a government vault for
50 years, then attack it (even more amusingly, they could simply
post it to Eternity themselves, encrypted with their own key :), a true
turn about).

If you do not postulate that level of signals collection capability on the
part of the attacker, yeah, Eternity is a bit different than email.  But
I think that would be an unreasonable model of the attacker.

- -- 
Ryan Lackey
rdl@mit.edu
http://mit.edu/rdl/		



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNMISuKwefxtEUY69AQFB1Qf9GWDn6bwhWyJcDY0Liypo21ntpH5yzORu
RXwkPSI8pbmqhVZAVGXC1WbcqY0pYn7vPRFq5AKszFsjpTOOYiHwsugmVKjrxVww
GRKSBqn308aAjMogNtPwEfohJrQxOED/Hy7ykV6gHV76pUFoMazQ4OdUL2iM1hLF
cCMzwtpfJM5eWvyLeQcQq307998epJ9hF1e3Sn4v6ZKEPIlr0yqr5tvM7/XWxC2s
6t82EUPmOZIbn75QQqLBIFK5MlOLuvalFr0xR3u7fYltOczAMC23hx7Tjk65e9a4
6XSeEXyMp2j2GWqcE5lUZp4OnewZvSoFhEj0rDo5PEN9ce0mJEKMow==
=7IBY
-----END PGP SIGNATURE-----