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)