Comments

t3knomanser • March 5, 2009 7:35 AM

That wikipedia article is too information light. “AONT prevents some kinds of attacks…”

What kind of attacks? How?

I’m not sure how this is useful. If the untransformed original is required to reverse the transformation, I fail to see how any benefit is derived.

Of course, it’s also early in the morning, I haven’t had coffee and haven’t been sleeping well lately.

Randy • March 5, 2009 7:54 AM

@t3

You sir are much better (or more awake) than I.

I read the staple/unstaple site and still don’t understand it.

Is this real or snake-oil?

Randy

noleti • March 5, 2009 8:06 AM

well, the use case is summarized at the end:

It has been suggested that this scenario occurs if Alice is a content producer/owner, Bob is a content piracy group, and Charlie is a user unconcerned about copyright infringement.

Bob wants to share Alice’s content, and wants to prevent Alice from prooving this, as this would require Alice to circumvent Bob’s copy protection mechanism

noleti • March 5, 2009 8:09 AM

which trivially means that the goal is not privacy, but a legal trick to make prosecution of file sharers harder, beating the content industry with their own weappons

Ralph Broom • March 5, 2009 8:11 AM

@Randy

I had my tea (grin). It appears to be a mechanism for protecting content pirates (on it’s face). The example in staple/unstaple indicates it intends to have a content owner violate the DMCA in order to prove that a distributor has distributed their content, infringing their rights. I don’t know if this has a sound legal basis, but it IS interesting.

So who can suggest substantial non-infringing uses for this concept?

stillsleepy • March 5, 2009 8:11 AM

@Randy, As far as I can tell this is an intellectual exercise by a cryptologist who likes to spend waaaaay too much time thinking about the DMCA. I fail to see any practical use for this other than giving one a way to use up all that extra processing power on their core2 3GHz box running slackware.

bob • March 5, 2009 8:12 AM

Ive had my coffee, RTAd, and still dont get it. (of course you have to consider that I drink decaf)

Why would I want to give someone something that they cant read/use?

greg • March 5, 2009 8:23 AM

you are all missing the point (i think).

All or nothing means just that. Even without a key. I don’t need the original data, but i do need all the transformed data in order to decode it.

ie i have all but 256 bits of a 10Gig file i still cannot transform it back to the original.

The idea is that every “key” check is expensive and hence makes any attack harder due to the fact you must always work on all the data.

Dave Aronson • March 5, 2009 8:31 AM

IANAL, but methinks it could also be useful if you need to prove in court that a document is complete, that neither party has omitted anything.

noah • March 5, 2009 8:38 AM

To provide another example (to those confused): You staple a file with itself. The only way to recover the original contents of the file is to have the entire file to run through unstaple. So by itself staple does nothing useful, because the file is the key.

Now you encrypt your stapled file using any normal public/private encryption scheme. If an attacker attempts to use an attack that would give them part of the original (the stapled file), this does them no good, because without the entire original, nothing can be decrypted (unstapled).

Guiro • March 5, 2009 8:54 AM

Either this scenario with Alice, Bob and Charlie is completely unrealistic or I don’t get it at all.

Why would Bob, a content piracy group, include the file B to which he has the copyright? I’m assuming here that the file B is used to identify Bob.

And even if Bob does that. What does Alice actually prove by brute forcing the key. There was some archive with file A and B, so what?

I probably just don’t get it. Interesting concept nevertheless.

noleti • March 5, 2009 8:58 AM

To prove that the shared file contains Alice’s content, she has to decrypt it (brute force the 2 bit key). But this would then also decrypt Bob’s content, which violates the DCMA. Therefore, Alice cannot prove Bob shares her content without violating the DCMA

Guiro • March 5, 2009 9:07 AM

Yes I get it now thanks. I was reading it with the wrong different mindset. I thought the goal was to protect Alice instead of Bob ;).

Anonymous • March 5, 2009 9:13 AM

Very Interesting.

I could see how this could make collection of certain type of data by third parties harder. If I were to exchange an AONT encrypted file as I understand it. The easedropper would need to whole file to process what occurred.

So, given an example of a large entity trying to monitor all data on a P2P or similar network…
either an RIAA entity or a government.

If AONT encryption were used with a small per user derived key/padding/salt/etc. The easedropper would have to record every block sent to that user to figure out what was actually sent to them, and would have to repeat the operation for each user. Especially if the block were exchanged via multiple routes only some of which the attacker could intercept … then the problem becomes worse for the attacker.

So, the attacker could not say: compute a message digest on random portions of a file without intercepting every block and reversing all the encryption each time. It could not prove any portion of the transmission was a block it knew was from a certain blacklist of data.

Even better a users could P2P a huge amount of data and the last block could be PGP’d and sent via usenet, faxed, read aloud over skype, emailed or via a large low bandwidth onion routing type setup.

In this kind of use case users could only swarm if they had a full set of the data. Which would lose some of the efficency of P2P, but still a reasonable tradeoff sometimes.

So, yes this seems like it could be a hugely useful technique.

Another useful trick I could see here is for mesh networking… Suppose two P2p users know they are local to each other and they don’t have any preshared information. They could directly exchange data via an ad-hoc network or wireless mesh networking or some similar short hard to ease drop distance. Since neither has the whole transmission they want … Other P2p clients could even facilitate this by doing something like secret sharing… I tell other nodes I can talk to by local friend. He does the same. The P2p nodes compute our last blocks and break it into two pieces we need to exchange to complete our transfer then we locally exchange our blocks.

Very interesting in my opinion as it could make something very like an onion routing network have decent bandwidth.

bitmonger

Jack • March 5, 2009 9:32 AM

Is it possible that resistance to innovation in this area is actually more harmful in the long run than poor security itself? Notice adversaries are free to innovate, though. Some people call anything they’re too lazy to read, or anything new and different just snake oil.

Uh oh, sounds like more snake oil!

BTW – in some places AONT is not considered encryption. I thought if it belonged to a complexity class and was verifiable, it was encryption. And another factor is if the output contains information that was not originally part of the plaintext, such as a random number used to steer an algorithm of some kind, than it is by definition encryption. Actually, the question of whether or not it is encryption is an important one, since it is possible to “secure” plaintext in ways that cannot be defeated, yet are not actually encryption so therefore an individual cannot be forced to divulge any “key” or password or random pad, etc.

Albatross • March 5, 2009 9:44 AM

There’s another issue to this, maybe.

Imagine in the scenario provided by the website that Alice is a regular user, and Bob is a privileged user. Bob obtains Alice’s information A, which is of a lower security confidentiality level. Then Bob staples his information B with Alice’s information A. But Bob’s information is of a HIGHER sensitivity level.

Now Alice cannot prove that Bob has appropriated her information without first violating DMCA, and second without violating security confidentiality.

This strikes me as potentially being a means to secret otherwise public information behind governmental privacy laws. If the court were doing discovery on Bob’s abuse of Alice’s information A, Bob could argue that his data cannot be decrypted because it would expose his governmentally-classified information B.

So if Bob were working for the government, and investigating Alice, he could put together a security file on Alice (B sub A), staple it with Alice’s public information A. When Alice files a FOIA request on her security file, the fact that she is even under investigation could not be revealed because it is stapled to BsubA?

Just mulling over the implication of this means of de-facto classifying unclassfied informations…

Sitaram • March 5, 2009 9:46 AM

re protecting pirates by forcing the copyright cops to violate the pirates’ copyright: wouldn’t rot-13 work as well?

greg • March 5, 2009 10:00 AM

@noah

“The file is the key” statement is just wrong. All or nothing transform is generally not keyed. You don’t need a key to reverse the transform any more than you need the original file.

As for legal protection against copyright infringement, i prefer the old and somewhat successful method of not breaching copyright in the first place.

Gweihir • March 5, 2009 10:10 AM

This is not a new Crypto primitive, AONTs have been studied for quite some time.

What this is, is putting an AONT into a nice package.

As to the uses of AONTs, it has mostly counter-forensic purposes. For example, if you have a file on disk that is confidential but needs to be there in plain, protecting it with an AONT means that if you overwrite it, an attacker has to recover all bits to get it. It seems that overwriting with a single pass of zeros on modern disks typicall prevents full recovery (and makes any recovery very expensive), thus preventing an attaker from getting parts of an overwritten file, while not needing a secret to access the full file before.

Note that “counter forensic” does not mean criminal. Criminals do forensicts too.

bitmonger • March 5, 2009 10:36 AM

This whole bizarre mix of crypto analysis and law I think is of limited value. Its fascinating on paper the law doesn’t work this way. At best is a fascinating schadenfreude moment. If you actually advocate this kind of reasoning as a way to fix a problem in the law… You are playing the wrong game.

Its possible the courts would narrowly act as agents of your clever protocol and find easedroppers guilty under DMCA, but if your intent was to use the DMCA to conceal violating the DMCA this seems like a stupid idea and one likely to hurt your cause (if you had one like: repealing/reforming the DMCA) this does not help it.

This just isn’t the way the law works. Intent matters. Impact matters. Benefit to society matters. Rights, Freedom, etc .. ultimately matter. Don’t play a small the game like this. If the law sucks fight it!

Behave ethically.

If you want to help your cause, vote, argue, blog, if you really care: be unimpeachable in intent.

Don’t fileshare things you think are a violation of your ethical principals.

If you intend civil disobedience, make sure it is seen as that not self-serving economic interest.

The law is crazy. People are being hurt by it there are serious civil issues not being fixed. Keep the focus on that.

I believe in secular government. I believe the law should defend people from harm, and protect their rights. Enable them to use their rights in practice not just theory. I believe destroying people’s reputation and financial future on the basis of a ‘more likely than not’ civil judgment in order to make ‘an example’ of someone is horribly unjust.

This must be stopped. It will take time.

Rule of law is important, as is fairness (aka: justice) . We lose rule of law when: we make all of our population in criminals, cowards, and cynics. As personal ethics and the law drift further apart it will only get worse.

So continue the legal tactics discussion if you like, because it is fascinating, but think about what you advocate. I don’t want people thinking they can use the law in a petty way and expect their problems to improve.

my $.02.

bitmonger

Paeniteo • March 5, 2009 10:36 AM

@Jack: “in some places AONT is not considered encryption.”

Wikipedia defines encryption as:
“In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.”

This sounds quite reasonable.
Hence, as long as you’d use this staple program without “forgetting” some parts, it wouldn’t be encryption as there is no key involved.
If you leave out some part of the data, it would be encryption as you’d need “special knowledge” to make it readable again.

IMHO, IANAL etc.

RH • March 5, 2009 10:58 AM

@Sitaram:
rot-13 allows for decryption of parts of the file. Alice could argue that she only decrypted her content (not Bob’s), so she did not violate DMCA (since apparently you’re allowed to flat out ignore your own copyright infringements on your own material).

With this technique, it forces Alice to violate DMCA, which Bob would then argue makes the file evidence gotten by illegal means, and move to dismiss the evidence.

The encryption properties are interesting though. One of the frustrations of encryption is that, when you find the key, you instantly start getting “useful” data letting you know the key is broken. It also is subject to attacks that only work “once in a while”. This system does a lot to minimize the effects of both.

Ross Snider • March 5, 2009 11:27 AM

The implications of the AONT on P2P charged by members of this discussion seems silly. At least AONT would break torrenting or be pointless.

Torrent files are really just collections of 1-way hashes of small pieces of the target file. Torrents work by verifying each small piece of the overall file as it get sent to client X against its hash.

So if you were to split a “stapled” file up into little piece, calculate hashes and share it over torrents the (insert big name organization here) would still be capable of figuring out exactly what you were pirating. If each individual client were to have a different seed/key associated with the AONT then the 1-way hashes would not match so the torrent model would not work.

I suppose it could be powerful for other types of P2P (the more server-to-client type). Am I missing something?

Perhaps, now that I think about it more, each file piece could be stapled together with an original work, perhaps something like a favicon or a small bit of personally mixed music or a personal quote. So it would work with torrenting, the question is how optimally.

Clive Robinson • March 5, 2009 11:43 AM

There are a few usefull asspects to AONT that spring immediatly to mind,

1, Timed product release.
2, Plausable deniability.
3, Protection of personal info and the like for compliance.

(1) If you wish to send out your latest master piece be it software film music book whatever. You AONT the file and but all but one block of it onto a CD or whatever and send it to them.

At a given point in time you send out the missing block by say multicast, then everybody gets it at the same release time (or later if they wish) but not before even though they have 99.999% of the work.

(2) Likewise you can send a work under AONT to many people and as a recipient you can store all of it except the missing block. You can show that without the block you cannot access any of the data and therefore cannot have seen the contents whatever they are.

(3) Likewise if somebody steals your laptop the files are effectivly locked beyond recovery without the missing block.

If you have the missing block on another piece of media or made available only over a VPN in an ephemeral way then it will solve a lot of issues to do with things like payroll and other static but valuable or confidential data.

The only problem is that as I understand it even with all the blocks AONT is not a random read so you have to exctract all of the data to memory of one form or another which kind of limits it’s usefulness for the third idea.

Tom • March 5, 2009 11:48 AM

If you can’t remember all the details of Block Cipher Modes, you could use AONT to achieve full error propagation regardless if cipher mode. If one block get slightly messed up, the entire file is unrecoverable.

Using it with an archive + compression could be useful from the perspective of how annoyed you get when a file is partially corrupted, but not completely and you may not notice. Now it would be unquestionably, completely corrupted.

The use of staple as a file-sharing/DMCA trick is an interesting thought experiment, but doubtful to be practical in a court of law.

Phillip • March 5, 2009 12:06 PM

I think everyone who is talking about the Torrent/DMCA aspect of this got it wrong.

The use of AONT is if you are afraid that the cipher you are using is weak and parts of the file could be exposed/cracked. AONT makes it so the attacker has to crack the entire file, not just a portion thereof, to use ANY of it.

This fellow was on the right track:
http://www.schneier.com/blog/archives/2009/03/all-or-nothing.html#c354850

Maybe we could get Bruce to chime in on it again?

noleti • March 5, 2009 12:11 PM

well, Bruce linked staple/unstaple, which seem to be specifially designed for this DCMA magic. Otherwise throwing away 2 bits of the key makes even less sense.

Of course AONT’s original purpose can be quite different

Tim • March 5, 2009 12:29 PM

You can’t use ‘tricks’ like this to get around copyright law. What will happen is this:

The MPAA sues you for pirating their film. They get money from you.

You have the option of suing them for pirating your added data/circumventing your copyright protection. You might win, but it’s not certain, and you probably wouldn’t win any damages because your data isn’t really worth anything.

noleti • March 5, 2009 12:35 PM

well, if the evidence for the prosecution has been gathering violating the law, it will probably not be admissible at court. This is the main point, imho. If the police searches your apartment without a warrant, evidence they find may not be used against you.

RH • March 5, 2009 2:56 PM

It looks like the big “strength” of AONTs is that they are forms of encryption with weak assumptions (meaning they are stronger encryptions).

Tricks like “delayed release” of software would be trivial to do using AES or other block ciphers.

They do seem to be designed to minimize data based tricks to prune a brute force search (such as only accepting encryption keys which result in printable characters for the first line).

David Donahue • March 5, 2009 4:05 PM

As someone who is not a Cryptographer (I know better), I was thinking that it’s primary use is to increase the brute force time for all encryption methods when executing an attack against a known plaintext.

Consider a 4GB DVD encrypted with staple and 3DES. When doing a brute force crypanalysis, there are a number of known plaintexts to search for to determine if you guessed the correct key. These tend to be things like file headers and standardized codec descriptions.

Before using staple, you could decrypt only the first block or two (a few seconds of decrypt time) and see if you got a match, but now you have to decrypt all 4GB (45 minutes of decrypt time) of the file just to determine if this key was incorrect and move on to the the next key guess.

So in short, it amplifies the brute force time by the number of blocks in the total file.

That’s got to increase the difficulty of cracking a key with brute force.

kme • March 5, 2009 4:36 PM

On the idea of forcing content owners to violate the DMCA to prove copyright violation there’s only one thing to say: Well played sirs, well played.

(It’s not about actually using it in a real court case – more just a thought experiment showing that the DMCA is inherently absurd).

Saibai • March 6, 2009 3:57 AM

@Clive Robinson
1) Why not send an encrypted file and later send the key?
2) For me, this works the same: If you don’t have the key, you cannot access the data.
3) And again, simply encrypting the content and storing the key on a seperate device. Furthermore, you don’t have to decrypt all your file, just to read an email.

Paeniteo • March 6, 2009 6:24 AM

@Clive: “There are a few usefull asspects to AONT that spring immediatly to mind,”

I don’t see any advantages to conventional encryption. (More precisely, I don’t see any difference whatsoever.)

The best argument I have read so far is that AONT prevents partial recovery of the plaintext (which shouldn’t be an issue anyway, if the encryption is done right.)

Seth Breidbart • March 6, 2009 9:07 AM

Tim, you missed some steps.

I have a file, AONT of a movie with my manuscript, keyed (with 2 bytes dropped).

The MPAA sues me. They claim I have a copy of their movie. I demand they prove it; they show my file and its decryption. I claim they decrypted my manuscript in violation of the DMCA, therefore they are coming to court with “unclean hands” and they lose.

Paeniteo • March 6, 2009 9:50 AM

@Seth:
They wouldn’t decrypt it themselves.
They would have a judge order you to decrypt it.

Anonymous • March 6, 2009 10:25 AM

The non-DMCA applications are interesting. The DMCA applications ignore the way that such cases have actually been prosecuted. *IAA doesn’t go around randomly breaking into computers, they just connect to trackers and p2p networks and note who is sharing which files. They make no effort to determine that the titles are accurate to the file size or contents (hell, I don’t think it’s even been shown that they distinguish between people connecting to their honeypot torrents or not).

Now, the idea of using AONT to prevent partial decryption and increase the time needed to brute force a key (granted, only a linear time increase) interests me. Will have to read more.

Greg • March 6, 2009 6:14 PM

This can work as a way for people who do not know each other to be introduced and verified by one mutually trusted party. Think spy v.s. spy.

In a very simple scenario, Mr. Kingpin creates a file and dices it up into 4 parts, and delivers one part a piece to 4 individuals who do not know each other, but who must trust each other when they first meet to do business.

They meet, assemble the archive by putting the pieces in the correct order and viola, if the archive unstaples they can all be trusted.

Matthew Flaschen • March 7, 2009 1:31 AM

Forgetting the legal arguments for a second, this could be useful for basically forcing integrity checking. Of course, people /should/ already be checking the sha1’s of the files they download. But since they don’t, we could just say, use “unstaple” to “unpack” the file. Then, if their download is corrupted, it will be extremely obvious because the unstaple will fail (due to the hash of at least one block changing). No more frustratingly corrupted ISOs.

Roger • March 7, 2009 4:29 PM

@Paenito:

I don’t see any advantages to conventional encryption. (More precisely, I don’t see any difference whatsoever.)

AONT was invented when the US government was imposing key length limits on cryptography. By performing an (unkeyed, non-cryptographic) AONT on a file before encrypting it with a weakened cipher, you can increase the effective strength of the cipher by a factor approximately equal to the number of blocks in the message. If you had a 64 bit block size (most ciphers did, back then) and your message is, say, 512 MB, then the AONT improves your security by about 26 bits, which changes 40 bit encryption into something reasonably useful.

Better, the system user gets to choose exactly how much strengthening occurs, and can do this independently of restrictions on the strength of the cipher. As such, AONT was an argument against the then current US government cryptography policies.

Actually, AONT has another advantage that wasn’t discussed as much, but is worth considering: it greatly increases the RAM requirements, or bandwidth, or both, for each node in a massively parallel cracking machine. This could increase the cost of such a machine by an enormous amount at the same time as requiring that it work enormously longer on each problem. Thus it has a sort of squared advantage in undermining the economics of cracking machines.

RonK • March 8, 2009 12:45 AM

I think a lot of comments, and the author of “staple”, miss an important point when they assume that the B work in the stapled file will be content copyrighted to the pirates themselves. It obviously would be much more interesting if the pirates included real commercially available works by many independent artists unassociated with A in the stapled file.

I agree that in the end this isn’t going to actually be effective at all, since law isn’t like cryptology, but it will surely give the **AA legal departments a lot to chew on before they come up with what they think is a safe, effective way to bypass it.

And if this ever comes into real use (which I doubt), then at least various indies will get better distribution. 🙂

RonK • March 8, 2009 1:57 AM

Another consequence of widespread use of AONT is that it makes automated checking of content for copyright infringement untenable. E.g., everyone makes content available, but uses staple with the key-blanking option so that a brute-force unstaple requires a home computer several hours to decrypt the content. This could make automated scanning a practical impossibility if enough content is posted. (And there could even be a secondary forum where the blanked key data is exchanged in disguised chatting.)

AONT also makes it a bit harder for the **AA’s investigators to show that a torrent is actually the content in question, because it would require downloading the entire file rather than just enough of the start of the file.

OTOH, some of this is better done with just a simple symmetric encryption with the key revealed in a small secondary file, in a way which requires human natural language parsing (“the key is ‘lskieAAl,maa;aAal-BOX-kej’ but with0ut punctuation and capital letters, and without the 3-letter English word for a rectangular container”)

yason • March 8, 2009 3:23 AM

Matthew Flaschen:

This is a good idea but just reduces to a custom file format that embeds the, for example, the sha hash of the payload. That too would require people to “unpack” before accessing the ISO. And on the other hand, the transparency of ISO binaries lacking error checking is rather convenient: you’ll just mount/burn it directly without having to unpack/untar/unzip/unstaple it which is what most people want to do anyway.

Then again, a HTTP sha1 checksum for the payload would be more transparent and as convenient.

Clive Robinson • March 8, 2009 6:29 PM

Just another point to throw into the pot.

Secure deleation of data.

Deystroying data is a lot more complicated and time consuming than most people realise (and in some cases down right environmentaly unfriendly).

If the data is stored using an AON Transform then the destruction of the data comes down to just destroying a very small part of it.

For instance backup tapes have a limited life, but destroying them is a real pain. With conventional storage even a small piece of such a tape could easily contain sensitive data.

With an AON Transform all you would have to do was cut out the first few inches of tape and burn it to know the rest of the tape was unrecoverable.

The same with other forms of storage, if you need to securly destroy an archive in an emergancy you probably do not have sufficient time to get even a couple of % done before the hords come over the parapet. However with an AON Transform just that fraction of a % does the job.

The more I think about them the more fun I can see with playing with AON Transforms 8)

Paeniteo • March 9, 2009 4:24 AM

@Clive: “With an AON Transform all you would have to do was cut out the first few inches of tape and burn it to know the rest of the tape was unrecoverable.”

Again, the same thing could be accomplished by simply encrypting your tapes’ content with a suitable cipher mode.
Furthermore, I’m not sure whether it is desirable to have backups which must be absolutely 100.00% intact to be recoverable at all…

Clive Robinson • March 9, 2009 7:07 AM

@ Paeniteo,

“Again, the same thing could be accomplished by simply encrypting your tapes’ content with a suitable cipher mode.”

The answer to that is both yes and no. Some cipher modes although “plaintext recovery” secure do leak other bits of information.

For instance simple chaining reveals at what point there is a difference. If you happen to know what that difference is it gives you an in and effectivly gives you a new start point to do a “known plaintext” attack…

With regard to,

“Furthermore, I’m not sure whether it is desirable to have backups which must be absolutely 100.00% intact to be recoverable at all…”

That is an issue not so much of security as liability.

The law does not care who “potentialy” loses the data that is in your custody you, your employees, outsourced data center, offsite repository or offsite confidential waste disposal company.

History has shown us that even the professionals with “real secrets” to keep (US Mil & NSA) have had disposal problems.

All a hot shot legal bod has to do is show that a tape is not properly acounted for and one record has appeared unexplainably to get a good chance of hitting with a class action…

Ultimately as I said it comes down not to security but liability, which is all about perception not actuality…

Roger • March 10, 2009 5:51 AM

@Clive:

If the data is stored using an AON Transform then the destruction of the data comes down to just destroying a very small part of it.

By the same token, corruption of a single byte renders your entire backup unrecoverable; not a good property for backup tapes.

Clive Robinson • March 10, 2009 6:10 PM

@ Roger,

“By the same token, corruption of a single byte renders your entire backup unrecoverable; not a good property for backup tapes.”

From the point of securing loss against yourself then yes I would agree with you. But what makes it easier for you (ie unprotected) makes it eaiser for others as well…

As I said earlier it’s a question of liability based on law and the perception of what can and cannot be done in the eyes of a jury after our legal bretheren have finished weaving their tapestries of words.

The cost of making a heavily encrypted backup secure against “self loss” should be considerably less even over an extended life time that the cost of “loss to others”.

I would rather make (say 5) additional copy backup tapes I know are not going to cost me big than ensure that just one that might is fully confidentialy destroyed.

Security is a difficult judgment call at the best of times and in this case two different aspects are pulling in opposit directions both with potentialy significant costs to any business that deals with confidential personal data (and which business does not these days).

grendelkhan • March 11, 2009 2:40 PM

It’s a lovely little system, and I can imagine plenty of uses for it. (Well, I can imagine using it to strengthen encryption, at least.) But the application the author has dreamed up is downright laughable. There’s an excellent essay by Matthew Skala (http://ansuz.sooke.bc.ca/lawpoli/colour/2004061001.php) which points out that an earlier iteration of this idea, “Monolith”, was predicated on a willful misunderstanding of how the law works, because it’s so different from the way CS works.

It’s important to separate the author’s crackheaded ideas about copyright from a very useful little tool, though.

Paeniteo • March 12, 2009 4:59 AM

@Clive: “I would rather make (say 5) additional copy backup tapes I know are not going to cost me big than ensure that just one that might is fully confidentialy destroyed.”

The need have more redundance means increased chances of loosing one of the tapes as a whole – e.g., when transporting them to off-site locations or similar.
Thus, you would need encryption anyway, which would make AONT pointless (e.g., in the case of GnuPG, it is sufficient to destroy the first few kilobytes of a file to render it unrecoverable – just the same as with AONT).

rambler78 • March 20, 2009 5:30 AM

If you can forgive my wide range of sins (late discovery, lack of crypto knowledge, and loooong post) I see several things that I would love to have verified/debunked:

Assumption: (1)
The strongest possible encryption against a brute force attack is reached when the key length is equal to the message length, a longer key will provide no better encryption.
(please bear in mind that I know only scraps about cryptology, and this may be a false assumption)

Corollary: (2)
If (1) is true then surely AONT offers a path to the strongest encryption possible via any given algorithm.

Assumption: (3)
Alice writes a message, performs an AONT (staple) and then sends the transformed message to Bob. Bob does not need to know anything aside from the AONT Alice used to transform the message back (unstaple).

Corollary (4):
If (3) is true and we ignore both compression, and possibility of Alice and Bob knowing different AONTs, then AONT offerers the smallest altered message Alice can send Bob that Bob can recover Alice’s original message from.

That’s a long winded way of trying to learn if there are other ways to alter a message (encrypting or using another mechanism) that do not change the length of the message sent.
I understand that zipping/compressing and encrypting are pretty similar tasks, and an algorithm can do both to minimise traffic, but this is still worth differentiating to me.
Random data will bloat, not compress when put through a zip/compression algorithm, and some data is essentially random (eg voice data). So it seems to me AONT could be offering the lowest traffic overhead possible on the alteration of random data (if it doesn’t require a key appended to the message).

I apologise for my long post, if I knew twice as much I’m sure I could have asked this in half the length. Any feedback would be appreciated, as long as it isn’t abusive.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.