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 deletion. 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.

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.

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 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.

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. 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.

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.

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 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)