Talk:Brute force attack

Origin

Much of this is taken from The FreeS/WAN docs [1] which I have permission User_talk:Sandy_Harris/Permission to re-use here, but I have rewritten quite a lot so I do not think it needs tagging as an external article at this point. Editors care to comment?

More generally, can others improve this?

Another dimension to key strength

Something not often considered in crypto for the civil sector, but often examined in depth in the military and intelligence areas, is not just how long a brute force (or more skilled) attack would take to yield the plaintext, but how long a period of protection is needed?

A classic example is that if you can hit a target with artillery in 5 minutes, but it would take the intended target 15 minutes to move out of range, the main reason to encrypt at all is the equivalent, I suppose, of giving the condemned a blindfold. Now, there might be a rationale for using encryption with resistance just slightly longer than the period between unit code name changes.

On the other hand, espionage traffic really should be protected for decades, because there are literally families of spies.

It happened that I was on the U.S. Federal Telecommunications Standards Committee at a time when one of the military members wanted the option for a longer checksum on -- IIRC -- HDLC. They said it was needed to protect nuclear command and control, and I inquired when the U.S. government had decided that the risk of accidental nuclear war was unacceptable at 16 bits but acceptable at 32 -- or maybe it was 32 and 64. My observation was not appreciated.

For things like money and securities trading, you do need strong protection until the trades are made, at which point the information is public. If the typical period between placing the order and making the sale is 15 minutes, how quickly would you have to break it and give it to another trader who could exploit the information?

I've had some generically weird experiences in clinical computing. In one case, the doctors insisted on very strong crypto (for 1966) for hard copies of lab charts they would leave unattended in hard copy. In another case, I became extremely frustrated with a client, who wanted strong security for an in-hospital hospital system on which an authenticated physician could prescribe narcotics. Trying for a reduction ad absurdum, I drew up a system that was generally more rigorous than used to order the launch of an ICBM. To get to the audit file, you had to have two people, at two locations, monitored by remote video links to two different guard centers, turn keys and enter their codes within 10 seconds of one another.

The client loved it. I went out and beat my head against the wall until it really felt good to stop.

Howard C. Berkowitz 23:51, 4 August 2008 (CDT)

In many cases, though, there is no extra cost to use better crypto. Stuff I've written on the question of using short keys or weak ciphers for some data is here [2]. It is far too polemical for an encyclopedia, and ignores issues like running out of random numbers or problems that may arise in managing larger keys, but I think it is basically correct.

In the artillery case, you might decide to go without cypto because it is faster or cheaper, or because simpler systems are more reliable. However, if you do decide to use crypto, it is likely worth using something strong. This blocks things like the enemy collecting a bunch of your fire orders so he can analyse your tactics and look for flaws. Sandy Harris 08:32, 5 August 2008 (CDT)

The point about building up patterns is well taken. In the case of artillery, since, at least in the U.S. and NATO, the system of coordinates and firing orders is very standardized and quite public. I am not going to try to rationalize the U.S. making the bombing of Cambodia TOP SECRET during the Vietnam War, since the surviving targets clearly knew they were being bombed. Oh well...it kept it mostly secret from the Congress and the voters.

You have set up a good example for the more general topic of communications intelligence, subset direction finding. It would be wise for whoever is being shelled to plot the locations of the firing positions, and perhaps work out a movement pattern, which is definitely the case with guerillas firing rockets and mortars. Noting the exact times is also relevant, because a security person might be able to correlate actions on the target side when they are fired on — and maybe more important, not fired upon. For example, they might observe that if they transmitted on HF at a power of 10 watts, it always drew fire, but nothing seemed to happen when they talked on UHF at 100 milliwatts. In other words, communications security, or electronic warfare#electronic protection, was a function less of crypto and more of power and frequency.

Since the direction in military crypto is greater automation, using stronger crypto is a reasonable direction. In practice, however, when the methods were pencil-and-paper or electromechanical (e.g., Enigma machine), the crypto clerks would try to save work and might do things that very much increased vulnerability.

Howard C. Berkowitz 19:40, 5 August 2008 (CDT)

Delete text?

I would like to delete most of Brute_force#Algebraic_attack, leaving only the first sentence and a link to Block_cipher#Non-linearity which covers the same ground more thoroughly. Sandy Harris 10:50, 26 October 2008 (UTC)

Did that, except I create a new algebraic attack article & made both this and Block_cipher#Non-linearity link to it. Sandy Harris 11:08, 2 November 2008 (UTC)

After more coffee, I'm going to take some paper and draw a little map. Chris has some quick diagramming software that may be better for the purpose.

What I'm trying to visualize is the relationships among these articles, which have places in multiple hierarchies. Very roughly, there's a cryptography/cipher/cipher type hierarchy (for both 1-way and 2-way communication), and there's a cryptanalysis hierarchy, which to some extent is subordinate to information security. In turn, cryptanalysis helps judge strength of crypto, while the problem analysis part of infosec helps determine how much strength is appropriate.Howard C. Berkowitz 12:59, 2 November 2008 (UTC)

In good shape

I'm comfortable with this. One minor thing -- might want to convert the embedded EFF link either to an external link or to an inline citation.

As I remember, I only did copy edits; I don't know if that is a bar to my being the only approver. I'm willing to nominate it. Howard C. Berkowitz 01:39, 21 March 2009 (UTC)

Since we have both a wikilink to our EFF article and a citation for the EFF-published book, I think we can just drop the link to the EFF website. It is not central to this discussion. Sandy Harris 06:47, 21 March 2009 (UTC)

Makes sense. Do you remember, without going through the histories, if I did more than copy edit? I don't think so. Ideally, it would be good to get another Editor to co-nominate. Is there anyone in Mathematics? Again, strong Related Articles helps a lot. EFF can move to External Links. Howard C. Berkowitz 16:08, 21 March 2009 (UTC)

Checking the history, you did only one edit that was not pure copy editing, adding "or there is a weakness in the algorithm. It is not the only attack against a cipher; there are other means including classic analytic cryptanalysis against a sufficiently simple cipher, chosen plaintext attacks, etc." to the end of first paragraph. I then rewrote it and made it a separate paragraph, the current second one. Your point survives, but not much of your text :-) Sandy Harris 05:14, 22 March 2009 (UTC)

The page has only about 60 edits overall, about 5 by you, someone adding the subpages tag, the rest by me. Sandy Harris 05:40, 22 March 2009 (UTC)

Plan for approval

Since this topic applies to telecommunications networks as well as computer systems, and we've been putting general telecommunications under the Engineering workgroup, I added Engineering to the workgroups and nominated it for Approval. Another Engineering editor can make the procedural judgment if my edits were substantive; I don't think they were. If so, then we would need another Editor or two.

We could also add Mathematics. Howard C. Berkowitz 01:26, 23 March 2009 (UTC)

So,... are you going to look for other Editors to join in on approval? Otherwise you're walking a fine line with this one, I think.--Joe Quick 02:43, 24 March 2009 (UTC)

It's tough, Joe. We are just plain short on editors. I've been trying for months to get a Computers editor for several articles of mine. I just don't know of anyone active with expertise in this area. Howard C. Berkowitz 03:18, 24 March 2009 (UTC)

The need for other editors has been discussed before, see Talk:Cryptography#Next_steps.3F for one example. But there are quite a few crypto-related articles that are close to approval, see User_talk:Howard_C._Berkowitz#Approvals.3F for a partial list, and almost the only people active in the area seem to be me as author and Howard (mainly) as editor. If you are an editor with time to look, or know of others, it would be greatly appreciated. Sandy Harris 03:22, 24 March 2009 (UTC)

Agreed. Sandy is right that there is a legitimate backlog; I picked this one because I regarded it as least controversial. I made more and more of a point of not doing direct collaborative editing so I could...ummm...remain chaste? to be an approving editor. Howard C. Berkowitz 03:48, 24 March 2009 (UTC)

From what I understand of this and other related articles, there is a lot of math that goes into encryption and attacks against encrypted material. But maybe less math for this particular attack than for others? Would it be appropriate to add the Mathematics Workgroup and recruit editors from there? --Joe Quick 14:52, 25 March 2009 (UTC)