A review of the Xipher Architecture White Paper (in progress ...)

[ksridhar]

1. at : In the abstract, the problem that is being addressed must be stated first, something like: enabling secure data sharing over insecure channels (which is there but hidden). Please showcase the problem first and then the technology. Consider an investor, inventor etc .., are they interested in the problem or the technology ?
2. There are two kinds of audiences that are being addressed, naive to cryptography (like me) and those who possess good enough knowledge. Please address the former while providing delineation for the latter. Else provide a statement about the targeted audience.
3. A set of terms would be really useful. See here for an example. Again this set the tone for
   • what the terms mean (for naive audiences)
   • usage of the same terms over the entire document
4. at : Xipher bridges this gap by enabling ... should not be under Motivation. Its the solution.
5. at : There are two things that i see
   • first is about the key and
   • second is about the data that is being encrypted using the key
     Please try to keep them separate so that the reader is bracketed while reading the document.

[ksridhar]

6. at we see ... asymmetric encryption ... being mentioned but at we see Symmetric Encryption Layer being mentioned. Seems unsettling to the reader.
7. at, the first time the word Component is used. What is the meaning of the term Component ? As mentioned earlier (#3) a section titled 'Terminology' will help.
8. at, what about the case when the input is say just a few bytes (eg: a AWS key), is streaming used even for this case ?
9. at, an observation. CPUs often process data efficiently in 32-bit words, 64-bit words. Aligned memory access can be faster on some architectures. This affects: Performance, Implementation simplicity.
10. at key has been mentioned as a parameter and also as the input at, where is this at ?

[ksridhar]

11. at, ... this produces ..., is this referring to ciphertext ? If so please mention, else delineate.
12. at 0:65536, is this [0, 65536) or (0, 65536] ? For if it is [0, 65536] we might get 65537 !
13. at is it that always 65,552 bytes are produced whether the input plaintext is 1 byte or 65536 bytes long ?
14. at i presume is a byte stream with no endian-ness meant. Forgive me, i come from a old school where this mattered.
15. at, site some link(s) for an interested reader.

[ksridhar]

16. at, please make a note that these are streaming compression algorithms.
17. at, why is this needed ? You can use a hyperlink to point to some code. There are open questions otherwise :
    • you are presuming that the reader knows go.
    • you may have to present snippets in python too for the benefit of readers who don't know go
    • as an algorithm at could be written as buf.Write(zWriter.Write(...)). What i am trying to say is keep the Algorithm language neutral.
    • at in go may need to rewritten something like func (w Writer) Write() int {...}
      In short, avoid language bias while presenting an algorithm. Avoid algorithm (or give an hyperlink) where the flow has been cleanly presented at
    • Code is a distraction in an architectural paper. What i mean is the reader wants to get the essence of your architecture and you are suddenly asking the reader to dive into code.
18. I see that the paper has two sections (for now, as i am not through with the paper completely), one an Architecture section and the other a design section. Till at i feel is the architecture section and may be beyond that is the design. Please dont mix the two. Architecture addresses the WHAT portion and the design the HOW portion. It is important that the reader should be able to walk away after the Architecture portion knowing that he has got the essence of the problem and the high level solution via the Architecture. The reader may be a investor or a important stakeholder perhaps not having the time to get into the details. In this context the Architecture section should be self contained.