Talk:Cipher

Constable help needed for unwarranted deletion of reference

Since I wrote some of the article, I may not be able to speak as a neutral editor, but I can see absolutely no justification for removing a citation, from one of the most authoritative textbooks in computer science, from the commentary about the need to generate random numbers by non-numeric means.

I cited, under Talk:One-time_pad some research that might suggest that it may be possible to generate pseudorandom sequences that are unpredictable, but I would want to spend a few hours on those proofs. There is no reason whatsoever for deleting the Knuth citation. Howard C. Berkowitz 21:08, 2 August 2008 (CDT)

Again, an unwarranted deletion of a citation

Since I wrote the Venona article, I believe I know what is in it. If, therefore, I believed that it was useful to wikilink to it, rather than having the direct citation in the references for this article, I would have done so. I did not. Sandy Berger has not explained the second deletion of a relevant citation. Howard C. Berkowitz 21:20, 2 August 2008 (CDT)

Constable Comment

I'm responding to a request above asking for constable intervention. What I see is an article that is under the Mathematics and Military workgroups. Howard would be considered an editor n this page and Sandy considered an author. First I'd like to say that, from an outsider perspective that knows nothing about content, the initial work that built this article was an excellent example of collaboration, so I thank you for that. In an effort to avoid prolonged and unproductive disagreements concerning content and style, Citizendium empowers editors with rights to use their expertise to decide the best use of content and style. Therefore, Howard has that control at this point and can place and replace anything that he feels appropriate. We trust that Howard will consider the concerns of all authors when making his decisions. I might also suggest that everyone use the talk page when deleting material as, under the certain circumstances, this is a blockable offense and a constable would be left with no alternative. D. Matt Innis 08:13, 3 August 2008 (CDT)

To get additional editor input, I am also adding the Computers workgroup. Most modern ciphers are computer-based, and the principles of encryption, within the broader context of information security, is an extremely relevant subject. Howard C. Berkowitz 09:43, 3 August 2008 (CDT)

Bulk encryption vs. Link Encryption

Howard just reverted [1] one of my edits. I think the edit was correct. RFC 4949 [2], which Howard helpfully cites, defines the terms as follows:

$ bulk encryption

     1. (I) Encryption of multiple channels by aggregating them into a
     single transfer path and then encrypting that path. (See:
     channel.)

     2. (O) "Simultaneous encryption of all channels of a multichannel
     telecommunications link." [C4009] (Compare: bulk keying material.)

     Usage: The use of "simultaneous" in definition 2 could be
     interpreted to mean that multiple channels are encrypted
     separately but at the same time. However, the common meaning of
     the term is that multiple data flows are combined into a single
     stream and then that stream is encrypted as a whole.

$ link encryption

     (I) Stepwise (link-by-link) protection of data that flows between
     two points in a network, provided by encrypting data separately on
     each network link, i.e., by encrypting data when it leaves a host
     or subnetwork relay and decrypting when it arrives at the next
     host or relay. Each link may use a different key or even a
     different algorithm. [R1455] (Compare: end-to-end encryption.)

Sandy Harris 03:28, 15 September 2008 (CDT)

Howard helpfully cites it because bulk and link are not interchangeable terms, and that bulk is the general term. Let user pairs AB, CD, and EF, all at different endpoints, be communicating to a gateway X at one end, and a gateway Y at the other. The end-to-end users may, indeed, have completely separate end-to-end cipher. If the connections A-X, C-X, and E-X, need protection against traffic analysis, there may be, in addition to the AB, CD, and EF end-to-end encryptions, separate encryptions AX, CX, and EX, all of which are true link ciphers.

Assume AX, CX, and EX all are over a LAN, and that A, C, and E do not trust one another. It is reasonable that these three encrypt all traffic except the layer 2 header necessary to traverse the LAN. Further, assume they have encryptors limited, hypothetically, to 50 Mpbs, which is adequate for any of their streams. Using the definition above, they are responsible, in cooperation with X, with the step that takes them to X.

When their traffic arrives at X, X may put the aggregate over a time-division multiplexed radio channel to Y. X is privy to the link decryption needed to accept frames from A, B, and C. Depending on the application, there might even be a supplemental packet header encryption if A were actually a gateway from A1, A2, and A3, but X may need access to the packet headers for such things as address translation, even though A had to link-protect A-A1, A-A2, and A-A3.

The X-Y channel runs at 500 Mbps, and needs a different and more expensive encryption than the 50 Mbps version. X feeds its traffic to a multiplexer R, perhaps which also receives the aggregate from the T side of another gateway for TU. R applies a 500 Mbps encryption to the XY and TU traffic to the RS channel; S, at the far end, decrypts RS and distributes by link to S and U. S looks at the headers, then link-encrypts S-B, S-D, and S-E.

An arrangement like this is quite common in military applications, and does appear in certain civilian applications, such as multiple levels of aggregation of financial information.

Sandy, at CZ, things often work better if before adding a chunk to an article where others have been working on it, it is certainly not required, but useful to mention on the talk page, "hey, I was thinking of adding something about foo. Anyone else have material on that? I was planning to discuss the implications of RFC 8765 and ISO 3456 on topic foo.

There is a much stronger case to preannounce your intention to revert or change others' work, unless you are doing it in a role as Editor. I did give an edit summary and a request to discuss when you reverted my work. That was not a snarky comment about "helpfully" providing the reference. I am suggesting these refinements, and even discussions because I might be wrong, because it is my job, as a relevant workgroup editor, to call attention, in a hopefully collaborative way, to material about which I have technical questions. Howard C. Berkowitz 08:53, 15 September 2008 (CDT)

Asymmetric stream ciphers?

Reverting one of my edits [3], Howard comments "(Please discuss deletion on the talk page. Is anything you deleted inaccurate?)". OK.

Yes, it is inaccurate; that's why I deleted it. I know of no asymmetric stream ciphers; it is not clear to me that they are even possible. There is no point to having different keys for encryption and decryption (the definition of asymmetric) if both generate the same pseudo-random stream. If they generate different streams (really different, not just something trivially related like a b c and -a -b -c), how would the cipher work? Sandy Harris 03:57, 15 September 2008 (CDT)

First, a deletion of others' work, even by an Editor, tends to call for discussion. Second, just for a start, it makes perfectly good sense to have a stream cipher for a point-to-multipoint transmission from some authority, be it a commander or simply a technical reference source A, to the set of users B1, B2, and B3, but separate point-to-point ciphers are needed for B1-A, B2-A, and B3-A.Howard C. Berkowitz 08:53, 15 September 2008 (CDT)

Sure that makes sense, but none of those ciphers would be asymmetric. Asymmetric crypto might be used for authentication in such a system, but not as a stream cipher since there are no asymmetric stream ciphers. Sandy Harris 20:16, 15 September 2008 (CDT)

Given that cryptology is not a field historically known for openness, although there certainly are current trends towards open discussion, I would think long and hard before saying something does not exist. It does seem true that symmetric ciphers require less computational power than asymmetric ciphers, and there has to be a good reason for using them. I may be completely wrong, but I have the sense that you have a number of underlying assumptions about the context in which communications security should operate. You mention authentication, which hadn't been part of the discussion. What is being authenticated?

We may not be talking about the same thing. What different streams are being generated? A sends the same stream to B1, B2, and B3. It is a one-way transmission of content. Why should A not be able to use a private key to encrypt but have a public decryption key should B(n+1) be added as a recipient? A sends the same stream, in a point-to-multipoint topology, to all Bx. A's security policy is that he wants to be the only generator of traffic for B's. The volume of traffic may be sufficiently small that setting up a symmetric session key isn't worth the added complexity. Your reference to different streams confuses me; in the example I describe, there is only one stream. Howard C. Berkowitz 20:37, 15 September 2008 (CDT)

Yes, I think we are talking about different things.

Which is one of the reasons that Editors here spend a fair bit of effort on consistent terminology, especially article titles and subheads having unambiguous meanings. Howard C. Berkowitz 11:48, 16 September 2008 (CDT)

If the cipher is asymmetric, then by definition there are two different keys for encryption and decryption. Do those two keys generate the same pseudorandom stream of data? If so, what is the point of having two keys? Anyone with either key can get that stream and use it either to encrypt or decrypt. You get none of the benefits of an asymmetric system; this does nothing that a single-key symmetric cipher cannot do.

I'm confused. Only the sender has (one) private key. The recipients all have the same private key. There is one stream being generated by the sender and received by the set of receivers. I would not suggest that the pseudorandom information generated to encrypt or decrypt is a "stream", but simply information internal to the encryption or decryption process. Howard C. Berkowitz 11:48, 16 September 2008 (CDT)

We are still talking about different things. I am talking about a straightforward stream cipher application with only one sender and one receiver. Does it make sense to have that system be asymmetrical, that is to use two different keys? No, for reasons I've given. You are talking about a system with multiple receivers. It is not clear to me why you introduced that; perhaps you just misunderstood my reference to the two streams of pseudorandom data which sender and receiver generate, taking it as a reference to encryption of multiple message streams? Anyway, that does not affect my argument; having different keys for sender and receiver makes no sense with multiple recipients either.

If the two keys give different pseudorandom streams, how does your cipher work? It cannot just use XOR as most stream ciphers do, since the two pseudorandom streams are different. You could make one stream +a +b + c etc and the other -a -b -c. bytewise add the first to encrypt and add the second to decrypt, but that's not interesting; it's really no different than having one pseudorandom stream, add to encrypt, subtract to decrypt. Something similar goes for any two pseudorandom streams with a simple mathematical relation.

What does "interesting" have to do with this article? Are you using it in some specialized way? I suggest that only a tiny proportion of humanity would find the most elegant encryption to be anything but incredibly dull.

Now, if you are using "interesting" to mean "applicable to real problems", that's different -- but call it "applicable to real problems" or some reasonably synonymous phrase.

I just meant that an asymmetric system which can trivially be converted into a symmetric system is not worth considering. It gives no advantage over the equivalent symmetric system, so why bother? Sandy Harris 12:28, 16 September 2008 (CDT)

If you try to use some more complex relation, like the RSA relation, the obvious approach has two problems. First, it is not a stream cipher anymore but a block cipher with a block size of your RSA modulus. Second, it has the overheads of repeated RSA operations, far too high for most stream cipher applications and for no obvious benefits — there are plenty of far cheaper stream ciphers that are believed secure.

An encyclopedia article is not about the commercial feasibility of algorithms and the computability. Further, there are applications where security is considerably more important than efficiency, and so little data is sent that adding some RSA cycles is insignificant. Specific example: it has been published that the Permissive Action Link (PAL) code on most U.S. nuclear weapons is 10 characters long. It may be sent within an Emergency Action Message (EAM) with operational details, but it again has been published that EAMs are in the tens of characters.

Missile launch orders are one way, ignoring the special cases of an acknowledgement or report of equipment malfunction, which are not as sensitive. I see one, one-way stream in the EAM being sent to the launchers. It may simply rely on TCP for acknowledgement. There are other communications systems that would be used for dealing with launch failures; those do not necessarily go to the EAM-issuing commander but to a local maintenance function.

By making the cryptosystem asymmetric, it becomes impossible for a miscreant missile crew to generate a forged EAM. Now, I grant with short messages, the boundary between authentication and content confidentiality are blurred, but we aren't talking about the applications of cryptography here; we are talking about the encryption and decryption. The proper question is "are there circumstances where the security policy does not want the recipient to have a valid encryption key?" The answer is "yes" in the nuclear launch control scenario, which is extreme but very real.

Sure, that is a real application and using RSA there would make sense. But it is not a stream cipher. It's a block cipher with your RSA modulus as the block size. Sandy Harris 12:28, 16 September 2008 (CDT)

Whether this sort of application is within the scope of things you find interesting does not define the CZ scope of what cryptologic matters may be covered or not covered. So far, you have yet to show me why an asymmetric stream cipher is impossible, which would be the only relevant question at this level of article. You have not even shown me why it is impractical for short messages. Howard C. Berkowitz 11:48, 16 September 2008 (CDT)

Granted, there may well be some less obvious approach that I'm not clever enough to see, but if so, it belongs in a research paper, not in an encyclopedia entry.

With all due respect, it is ultimately the decision of a workgroup editor, a group of workgroup editors, the Editorial Council, or the Editor-in-Chief to decide what does and does belong in CZ. In some subjects and workgroups totally separate from this, there are fairly heated discussions on inclusion versus exclusion. Larry Sanger, the Editor-in-Chief, describes himself as more of an inclusionist than an exclusionist.

To put it a different way, arguments about what you want excluded aren't particularly relevant on an article talk page. A Forum might be a better place, probably Computers, perhaps Military, or general article policy. Howard C. Berkowitz 11:48, 16 September 2008 (CDT)

Your example makes little sense to me. If A is sending the same material to B1, B2 etc. then either he encrypts each copy the same way and all recipients have the one decryption key or he encrypts each copy differently and each recipient has his own key. In either case, he uses some symmetric algorithm for the encryption, either a stream cipher or a block cipher. Those are the standard way to do the heavy lifting of encrypting the main data transmission. Asymmetric (public key) algorithms are too expensive for that.

It is not too heavy for a 20 character message. You are making unspoken assumptions about the application, the cost of implementing the cryptosystem, and the additional security from not making the encryption key available. If we were talking about secure cellular telephony, I would agree that asymmetric stream technology is probably uneconomic there, but we are not talking about a specific application. Howard C. Berkowitz 11:48, 16 September 2008 (CDT)

Asymmetric crypto is routinely used in two main places. One is authentication. There are other authentication mechanisms, e.g.the hash-based HMAC construct IPsec uses to authenticate packet contents and various techniques using shared secrets and symmetric crypto. But digital signatures, X.509 and other certificate schemes, secure DNS, PGP signing, ... all use public key methods to authenticate things. In your example, A might sign his messages so the B's would know they were legitimate, or public key methods might be used to authenticate A and Bn to each other during a Diffie-Hellman key negotiation protocol as is done (optionally; there are other methods) in IPsec.

The EAM case is not one of authentication alone, but also content confidentiality of an extremely sensitive payload. Howard C. Berkowitz 11:48, 16 September 2008 (CDT)

The other major use of asymmetric crypto is as a component in hybrid systems. e.g. in PGP, the main encryption of email is done with a symmetric block cipher (CAST-128 or maybe now AES, I haven't looked recently). To send you a message, I generate a random key for that block cipher, encrypt the message with it, then encrypt that random key with your public key. You use your private key to decrypt the random key, then use it to decrypt the message itself. We each do one expensive public key operation. This is definitely worthwhile; without the publc key techniques, symmetric crypto systems have a key management problem.

Going back to the original point, what I deleted was the sentence "They may be symmetric, with the same key used for encryption and decryption, or asymmetric, with different encryption and decryption keys." In the context of a discussion of stream ciphers this is an error.

I think the correct organisation is to say there are two types of crypto, symmetric (conventional, secret key) and asymmetric (public key). Then it breaks down further; there are two types of symmetric algorithm, block ciphers and stream ciphers. Sandy Harris 10:40, 16 September 2008 (CDT)

Sorry, I can't agree. Symmetric and asymmetric cryptography are not irrevocably linked to block and stream implementation.

Can we "get a second opinion" here, ask another editor to have a look? I think you and I are both trying hard to collaborate, but we seem to end up spending more time arguing than actually writing the encyclopedia. I'm more than a little frustrated by that and imagine you are too. Sandy Harris 12:28, 16 September 2008 (CDT)

Honestly, I am having a related problem -- I can't approve an article I wrote, and the editors that are lower-layer specialists are not responding to mail. Since two of the articles are general in nature, I just sent it to someone who is active and is an application-layer person, whom I hope responds. If you know anyone that would like to become an editor, invite them! Noel Chiappa would probably be able to comment here, but he isn't answering email.

I do suggest the Forums, and perhaps not even the Computers workgroup but something such as general articles and article policy. I suspect, Sandy, that we are disagreeing on more than the technical details, but on the scope of what should be in articles and if articles should be present at all. I may be wrong, but some of the things you are saying, even in phrasing, remind me of things I say when I'm developing software -- that something is uninteresting, or that it might be inefficient. When I got more into requirements and architecture, I had to use a different viewpoint. Efficiency was a relative term -- for example, it is quite irrelevant, in weapons, how much inefficiency there is in some computation if that computation will be done many times. If the computation is done once and then the computer becomes part of a fireball, the only question of efficiency is whether the computation could be completed in time, and securely.

I agree we are probably talking about different things, and I have a sense you have some quite specific contexts in mind. I have tried to offer scenarios as well, but you have offered scenarios that are inherently executed multiple times (e.g., electronic mail), or where there might be two-way exchanges either from the sender to the receiver or from the receiver to a key distribution center/certificate authority. Weapons may not be able to exchange, because they MUST be passive or there's a danger that their electromagnetic emissions will compromise them. I'm not limited to military examples alone; I can think of examples in medicine and in things like electrical power grids where the messages are short and utterly critical.

One other thought

Try constables@citizendium.com. Matt Innis is most likely to respond. While he can't comment on the content specifics, both in terms of his role and that this is not at all his professional area, I think he might clarify the ideas about inclusion and exclusion, interesting/practical and not. There are other people, some on the Editorial Council, that have been known to mediate outside their area of specialization, although it's always better to have someone familiar with the subject.

A while back, you made what was probably an accurate observation -- you are bottom-up and I am top-down. Nothing wrong with that; I'm indeed bottom-up when I'm prototyping and I need a proof of concept. Part of the problem here, however, is in the lack of the "top" articles and "middle" articles. You may have something very specific and reasonable in mind, but it is specific to a particular context and the context isn't well defined.

I've also noticed that you seem to want only certain things in an article, and have deleted citations from articles. I honestly don't understand -- I'm speaking of an emotional perception here, but it feels like you want to cut articles back only to that which you think is important. I've had that feeling on material that I have written, and from which you removed content, either without explanation or with an argument it was irrelevant. That kind of outlook is a Good Thing if we were trying to produce tight code. It isn't necessarily the best approach to articles. Howard C. Berkowitz 12:50, 16 September 2008 (CDT)

Another try at this

I left this question alone a while, but it seems like it may be time to re-visit it.

The text in question is "Stream ciphers are not tied to blocks, but apply a continually generated key to an arbitrary length sequence of symbols. They may be symmetric, with the same key used for encryption and decryption, or asymmetric, with different encryption and decryption keys." I deleted the second sentence.

As I see it, that sentence is just wrong. Stream ciphers, like block ciphers, are a class of symmetric cipher; the same key is used on both ends. Asymmetric or public key crypto is a higher-level category, and not the one that includes stream ciphers. Saying that stream ciphers can be symmetric or asymmetric is like saying vertebrates can be animals or plants; it has the order of the classification hierarchy mixed up.

That's the essential point. My speculation on how an asymmetric stream cipher (vertebrate plant) might work are irrelevant. Howard's introduction of RSA to secure short messages, using a public key technique as a block cipher, is also off the point. The plant/animal distinction may be blurry in places, but the classification still excludes vertebrate plants. Sandy Harris 03:48, 31 December 2008 (UTC)

Believe me, Sandy, I'm not trying to avoid things that might seem obscure, but there are so many things in the history of cryptology, such as superencipherment, separate authentication systems that simply identify or perhaps are the GO-command for an operations or weapons release, such that I'm hesitant to exclude techniques that might be combined. It is, however, perfectly reasonable to exclude, perhaps with a brief explanation, things that we know have vulnerabilities. Even there, however, there are applications, often military but including such things as financial market transaction, where protection in minutes or hours is all that is needed. Howard C. Berkowitz 16:56, 4 January 2009 (UTC)

Other editors?

Howard is now gone, & he was the only one arguing against this change. Anyone else want to comment before I delete the sentence? Sandy Harris 04:17, 1 September 2011 (UTC)

Workgroup membership

(Specifically to Howard) Appreciate the work you've done on these articles, but I don't think they should be in the Military Workgroup. It is clear why they are - the military is one of the primary users of cryptography - but there are plenty of civilian uses also - in government, business and so on. Mathematics and Computers Workgroup seem obvious candidates, but the Military one sticks out a little - why that and not, say, Business or - as many ciphers were created by medieval monks - Religion or History? --Tom Morris 09:56, 12 October 2008 (UTC)

First, assume that I and many other assume military to include all forms of national intelligence. Not many ciphers were created by anyone in the medieval period, but, until quite recently, the bulk of advanced ciphers -- and cryptanalysis -- were coming from the military (in this broad sense). I'll note that I am both a Computers and Military Workgroup Editor and have had direct experience in both, so I suggest I might be trying to be objective.

There have been various assertions that "principle X" isn't useful. I might observe "but principle X" is exactly how the NSA-QRS-333 works. There could be a counter of "well, they don't need to do that," and the answer, which usually draws on unclassified sources, is "no, they had a specific reason for doing so." Often, their non-obvious reasons have to do with the scale on which they operate, and the need to use specific techniques because other techniques don't scale. While the entertainment industry may encrypt content, they don't face the scaling issues of someone sending the aggregate field-to-national-headquarterss of a large military, or the downlink from a high-volume intelligence sensor.

Another area is that cryptologic techniques often blur with things that, for want of a better phrasing, use cryptology for other than pure information security. Example: it's quite possible to use very similar key management and session key generation to drive a frequency-agile spread spectrum (FASS) communication system. FASS does decrease the probability of intercept and thus cryptography — or traffic analysis if the content is in the clear — but FASS is just as much about efficient spectrum use, minimizing the probability of intercept, and being jam-resistant as it is as about obscuring content. I'll add to that, especially when the key-generator-driven methods selects among different transmitters, it also interferes with geolocation.

Is there a problem being created by having the military group? If so, what is it, other than a sense of it not fitting as well as others?Howard C. Berkowitz 15:17, 12 October 2008 (UTC)

Crypto is not purely math, but I'd say it clearly belongs in the math workgroup. It is not only done on computers or only used by the military, but it is certainly important in both areas. I see no objection to having it in those workgroups, unless CZ has a policy I don't know about saying we should try to keep the number of workgroups for an article small. Sandy Harris 15:40, 14 October 2008 (UTC)

I'm confused. I thought you were objecting to it being in the military workgroup. Unless there was an oversight, the general topics should always have been in the Military and Mathematics workgroups; historical manual systems are the only ones that should not have been in Computers. It's desirable not to have an extreme number of workgroups, but I've seen 4-5 be reasonable. Especially when there is a shortage of editors, additional workgroups are useful in the hope of getting approvers when needed; at present, I seem to be the only active Military editor, and there are a few Computers editors that have very limited time. As far as Mathematics editors, I don't know the status.

In other words, I don't see a problem. Do you?Howard C. Berkowitz 16:03, 14 October 2008 (UTC)

It wasn't me objecting to the military workgroup. As I said above "I see no objection ...". Sandy Harris 16:08, 14 October 2008 (UTC)

Apologies, Sandy. I see it was Tom. Tom, does this explanation satisfy you? Howard C. Berkowitz 16:19, 14 October 2008 (UTC)