Re: [Cryptography] encoding formats should not be committee'ized
On 4/10/13 11:17 AM, Peter Gutmann wrote: Trying to get back on track, I think any attempt at TLS 2 is doomed. We've already gone through, what, about a million messages bikeshedding over the encoding format and have barely started on the crypto. Can you imagine any two people on this list agreeing on what crypto mechanism to use? Or whether identity-hiding (at the expense of complexity/security) should trump simplicity/security 9at the expense of exposing identity information)? Au contraire! I think what we have shown is that the elements in dispute must be found in the competition. Not specified beforehand. Every proposal must include its own encoding, its own crypto suite(s), its own identity-hiding, and dollops and dollops of simplicity. Let the games begin! iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2/10/13 00:16 AM, James A. Donald wrote: On 2013-10-02 05:18, Jerry Leichter wrote: To be blunt, you have no idea what you're talking about. I worked at Google until a short time ago; Ben Laurie still does. Both of us have written, submitted, and reviewed substantial amounts of code in the Google code base. Do you really want to continue to argue with us about what the Google Style Guide is actually understood within Google? The google style guide, among other things, prohibits multiple direct inheritance and operator overloading, except where stl makes you do operator overloading. I do similar. I prohibit reflection and serialization in java. In C I used to prohibit malloc(). Thus it certainly prohibits too-clever code. The only debatable question is whether protobufs, and much of the rest of the old codebase, is too-clever code - and it certainly a lot more clever than operator overloading. protobufs I would see as just like any external dependency -- trouble, and not good for security. Like say an external logger or IPC or crypto library. It would be really nice to eliminate these things but often enough one can't. On the other hand, if you are not so fussed about security, then it is probably far better to use protobufs to stop the relearning cycle and reduce the incompatibility bugs across a large group of developers. Such prohibitions also would prohibit the standard template library, except that that is also grandfathered in, and prohibits atl and wtl. The style guide is designed for an average and typical programmer who is not as smart as the early google programmers. If you prohibit anything like wtl, you prohibit the best. Right. Real world is that an org has to call on the talents of a variety of programmers, high-end *and* aspirational, both. So one tends to prohibit things that complicate the code for the bulk, and one tends to encourage tools that assist the majority. I'd probably encourage things like protobufs for google. They have a lot of programmers, and that tends to drive the equation more than other considerations. Prohibiting programmers from using multiple inheritance is like the BBC prohibiting the world literally instead of mandating that it be used correctly. It implies that the BBC does not trust its speakers to understand the correct use of literally, and google does not trust its programmers to understand the correct use of multiple direct inheritance. I often wish I had some form of static multiple inheritance in Java... iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Thu, Oct 3, 2013 at 1:35 PM, Lodewijk andré de la porte l...@odewijk.nlwrote: IMO readability is very hard to measure. Likely things being where you expect them to be, with minimal confusing characters but clear anchoring so you can start reading from anywhere. If someone could write a generative meta-language we can then ask people to do text comprehension tasks on the packed data. The relative speeds of completing those tasks should provide a measure of readability. I don't like anyone arguing about differences in readability without such empirical data. (it's all pretty similar unless you design against it I guess) XML is actually surprisingly readable. JSON is a lot more minimal. I find its restrictions frustrating and prefer using real JAVASCRIPT OBJECT NOTATION wherever possible, like INCLUDING FUNCTIONS and INCLUDING 'THIS' REFERENCES. Harder on parses, but why would you write your own anyway? (No, your language is not archaic/hipster enough not to have a parser for a popular notational format!) What part of the Chomsky hierarchy do you not understand? What part of running computations on untrusted data which amount to Turing machines sounds like a good idea? The trivial DDOS, or the oh-so-amusing use as part of a distributed computing service? What dangers of multipass computation on potentially ambiguous data do you think are worth the extra connivence? And let's not forget the bugs that context-sensitive grammars invite. I think that's the most useful I have to say on the subject. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
d...@geer.org writes: The (U.S.) medical records system that started at the Veterans' Administration and has now spread to all but all parts of the U.S. Federal government that handle electronic health records is ASCII encoded, and readable. Called The Blue Button,[1] there is even an HL7-Blue Button file converter.[2] Score one for human readable. Things like HL7 and EDIFACT/X12 (and ASN.1 in DER/BER form) were never meant to be human-readable, they're meant to be easily machine readable and processable. This is why you have viewers to turn them into human-readable form in any format you want. The problem with formats like XML is that it's never been quite sure what it wants to be, so that the result is neither easily human-readable nor easily machine-readable. Trying to get back on track, I think any attempt at TLS 2 is doomed. We've already gone through, what, about a million messages bikeshedding over the encoding format and have barely started on the crypto. Can you imagine any two people on this list agreeing on what crypto mechanism to use? Or whether identity-hiding (at the expense of complexity/security) should trump simplicity/security 9at the expense of exposing identity information)? Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Jerry Leichter leich...@lrw.com writes: My favorite more recent example of the pitfalls is TL1, a language and protocol used to managed high-end telecom equipment. TL1 has a completely rigorous syntax definition, but is supposed to be readable. For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-02 23:09, Phillip Hallam-Baker wrote: No, the reason for baring multiple inheritance is not that it is too clever, it is that studies have shown that code using multiple inheritance is much harder for other people to understand than code using single inheritance.� That is because of the class of problems for which it is appropriate to use multiple inheritance. The original reason multiple inheritance was added to C was to support collections. Was it? And regardless of whether that was the reason, not what it is used for today. So I can't see where C++ is helping. It is reducing, not improving my productivity. C++ greatly improves my productivity, in particular the memory management classes std::unique_ptr and std::shared_ptr, though if using them means you have to use std::weak_ptr, then one has to pause and think. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. utter_tangent The (U.S.) medical records system that started at the Veterans' Administration and has now spread to all but all parts of the U.S. Federal government that handle electronic health records is ASCII encoded, and readable. Called The Blue Button,[1] there is even an HL7-Blue Button file converter.[2] Score one for human readable. /utter_tangent --dan [1] www.va.gov/BLUEBUTTON/Resources.asp [2] www.hl7.org/implement/standards/product_brief.cfm?product_id=288 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-03 09:49, Peter Gutmann wrote: Jerry Leichter leich...@lrw.com writes: My favorite more recent example of the pitfalls is TL1, a language and protocol used to managed high-end telecom equipment. TL1 has a completely rigorous syntax definition, but is supposed to be readable. For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. Then that puts it in the same category as HBCI version 1. Sure, it was rigorous. Sure, it was unambiguous. Sure, it was ASCII-encoded. But human-readable? I implemented that protocol once, and can assert that, after reading more HBCI messages than was probably good for me, I felt decidedly less than human. Fun, Stephan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
IMO readability is very hard to measure. Likely things being where you expect them to be, with minimal confusing characters but clear anchoring so you can start reading from anywhere. If someone could write a generative meta-language we can then ask people to do text comprehension tasks on the packed data. The relative speeds of completing those tasks should provide a measure of readability. I don't like anyone arguing about differences in readability without such empirical data. (it's all pretty similar unless you design against it I guess) XML is actually surprisingly readable. JSON is a lot more minimal. I find its restrictions frustrating and prefer using real JAVASCRIPT OBJECT NOTATION wherever possible, like INCLUDING FUNCTIONS and INCLUDING 'THIS' REFERENCES. Harder on parses, but why would you write your own anyway? (No, your language is not archaic/hipster enough not to have a parser for a popular notational format!) I think that's the most useful I have to say on the subject. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 09/30/13 04:41, ianG wrote: Experience suggests that asking a standards committee to do the encoding format is a disaster. I just looked at my code, which does something we call Wire, and it's 700 loc. Testing code is about a kloc I suppose. Writing reference implementations is a piece of cake. Why can't we just designate some big player to do it, and follow suit? Why argue in committee? early 90s annual ACM SIGMODS (DBMS) conference in San Jose ... general meeting in (full) ballroom ... somebody in the audience asks panel on the stage what is all this x.5xx stuff about ... and one of the panelists replies that it is a bunch of networking engineers trying to re-invent 1960s DBMS technology. CA industry is pitching $20B/annum business case on wallstreet ... where the financial industry pays CAs $100/annum for every account for a relying-party-only digital certificate ... where the financial industry providing all the information that goes into the certificate (CA industry just reformats all the information and digitally signs it). In one case of institution with 14M accounts, the board asks what is this $1.4B/annum thing about? I repeatedly point out that it is redundant and superfluous since the institution already has all the information. Purpose of the certificate is to append to every financial transaction. I also point out that digital certificate payload is enormous bloat, 100 times larger than the transaction size its attached to (besides redundant and superfluous) CA industry then sponsors x9.63 work in X9 financial standards industry for compressed certificate format ... possibly getting the payload bloat down to 10 times (instead of hundred times). Part of the compressed certificate work was to eliminate fields that the relying party already had. Since I had already shown that the relying party (institution) already had all fields, it was possible to compress every certificate to zero bytes ... so rather than doing digitally signed transactions w/o certificates ... it was possible to do digitally signed transactions with mandated appended zero-byte certificates. Trivia: last few years before he passed, Postel would let me do part of STD1. There was a joke that while IETF required at least two interoperable implementations before standards progression, ISO didn't even require that a standard be implementable. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Replying to James and John. Yes, the early ARPANET protocols are much better than many that are in binary formats. But the point where data encoding becomes an issue is where you have nested structures. SMTP does not have nested structures or need them. A lot of application protocols do. I have seen a lot of alternatives to X.509 that don't use ASN.1 and are better for it. But they all use nesting. And to get back on topic, the main motive for adding binary to JSON is to support signed blobs and encrypted blobs. Text encodings are easy to read but very difficult to specify boundaries in without ambiguity. Responding to James, No, the reason for baring multiple inheritance is not that it is too clever, it is that studies have shown that code using multiple inheritance is much harder for other people to understand than code using single inheritance. The original reason multiple inheritance was added to C was to support collections. So if you had a class A and a subclass B and wanted to have a list of B then the way you would do it in the early versions of C++ was to inherit from the 'list' class. I think that approach is completely stupid, broken and wrong. It should be possible for people to make lists or sets or bags of any class without the author of the class providing support. Which is why C# has functional types, ListT. Not incidentally, C also has functional types (or at least the ability to implement same easily). Which is why as a post doc, having studied program language design (Tony Hoare was my college tutor), having written a thesis on program language design, I came to the conclusion that C was a better language base than C++ back in the early 1990s. I can read C++ but it takes me far longer to work out how to do something in C++ than to actually do it in C. So I can't see where C++ is helping. It is reducing, not improving my productivity. I know that some features of the language have been extended/fixed since but it is far too late. At this point it is clear that C++ is a dead end and the future of programming languages will be based on Java, C# (and to a lesser extent Objective C) approaches. Direct multiple inheritance will go and be replaced by interfaces. Though with functional types, use of interfaces is very rarely necessary. So no, I don't equate prohibiting multiple direct inheritance with 'too clever code'. There are good reasons to avoid multiple inheritance, both for code maintenance and to enable the code base to be ported to more modern languages in the future. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Oct 2, 2013, at 10:46 AM, Viktor Dukhovni cryptogra...@dukhovni.org wrote: Text encodings are easy to read but very difficult to specify boundaries in without ambiguity. Yes, and not just boundaries. Always keep in mind - when you argue for easy readability - that one of COBOL's design goals was for programs to be readable and understandable by non-programmers. (There's an *immense* amount of history and sociology and assumptions about how businesses should be managed hidden under that goal. One could write a large article, and probably a book, starting from there.) My favorite more recent example of the pitfalls is TL1, a language and protocol used to managed high-end telecom equipment. TL1 has a completely rigorous syntax definition, but is supposed to be readable. This leads to such wonderful features as that SPACE is syntactically significant, and SPACE SPACE sometimes means something different from just SPACE. I have no idea if TL1 messages have a well-defined canonical form. I doubt it. Correct TL1 parsers are complicated and if you need one it's generally best to bite the bullet and pay to buy one from an established vendor. Alternatively, you can go to http://telecom-info.telcordia.com/site-cgi/ido/docs.cgi?ID=SEARCHDOCUMENT=GR-831; and pay $728 for a document that appears to be less than 50 pages long. Oh, and you may wish to refer to 6 other documents available at similarly reasonable prices. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Mon, Sep 30, 2013 at 9:41 AM, Mark Atwood m...@mark.atwood.name wrote: Well, there are Protobufs, and there is Thrift, and there is MessagePack, and there is Avro... Here's a crazy idea: instead of using one of these formats, use a human readable format that can be described by a formal grammar which is hopefully regular, context-free, or context-sensitive in a limited manner -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 1 October 2013 01:10, James A. Donald jam...@echeque.com wrote: On 2013-10-01 04:22, Salz, Rich wrote: designate some big player to do it, and follow suit? Okay that data encoding scheme from Google protobufs or Facebook thrift. Done. We have a complie to generate C code from ASN.1 code Google has a compiler to generate C code from protobufs source The ASN.1 compiler is open source. Google's compiler is not. Ahem: https://code.google.com/p/protobuf/downloads/list. Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Wat? Sez who? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 1 October 2013 09:46, James A. Donald jam...@echeque.com wrote: On 2013-10-01 18:06, Ben Laurie wrote: On 1 October 2013 01:10, James A. Donald jam...@echeque.com wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Wat? Sez who? Protobufs is code generating code. Not allowed by google style guide. News to me - where does it say that? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Mon, Sep 30, 2013 at 6:04 PM, Mark Atwood m...@mark.atwood.name wrote: YAML? YAML is a bit insane ;) There's JSON, and also TOML: https://github.com/mojombo/toml -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Mon, Sep 30, 2013 at 6:17 PM, Mark Atwood m...@mark.atwood.name wrote: YAML is a superset of JSON C++ is a (not completely proper) superset of C. Does that make it better? ;) is more human readable, and, unlike JSON, has internal references. YAML also has the property that indentation mistakes can radically alter the interpretation of a file. And on Ruby, it was a remote code execution vulnerability waiting to happen. -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Sep 30, 2013, at 8:10 PM, James A. Donald wrote: We have a complie to generate C code from ASN.1 code Google has a compiler to generate C code from protobufs source The ASN.1 compiler is open source. Google's compiler is not. http://code.google.com/p/protobuf/source/checkout. BSD 3-clause license. Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. I have no idea what this means. I can tell you with certainty that all kinds of clever code is being developed and deployed within Google (though I can't give you any details, of course). Some of it may eventually get described in the open literature; some of it may be open-sourced. Personally, I have no deep objections to ASN.1 - though much of its complexity has been proved unnecessary by the usage of other, much simpler, approaches, like protobufs. Still, once you have compiler for it, it doesn't really matter all that much either way. For crypto algorithms, you're unlikely to want or need the more obscure corners. Do keep in mind, however, that having just a way to generate C from ASN.1 no longer covers much of the necessary space, as there are now many popular languages that are no C-like. Some are easy to bind to C libraries (e.g., Python); others are much more difficult (e.g., Java). For ease of use, you really want generators that produce code well integrated into the target language, no some barely functional glued-together thing. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Here's a crazy idea: instead of using one of these formats, use a human readable format that can be described by a formal grammar which is hopefully regular, context-free, or context-sensitive in a limited manner YAML? On Mon, Sep 30, 2013 at 5:48 PM, Tony Arcieri basc...@gmail.com wrote: On Mon, Sep 30, 2013 at 9:41 AM, Mark Atwood m...@mark.atwood.name wrote: Well, there are Protobufs, and there is Thrift, and there is MessagePack, and there is Avro... Here's a crazy idea: instead of using one of these formats, use a human readable format that can be described by a formal grammar which is hopefully regular, context-free, or context-sensitive in a limited manner -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
YAML is a superset of JSON, is more human readable, and, unlike JSON, has internal references. On Mon, Sep 30, 2013 at 6:14 PM, Tony Arcieri basc...@gmail.com wrote: On Mon, Sep 30, 2013 at 6:04 PM, Mark Atwood m...@mark.atwood.name wrote: YAML? YAML is a bit insane ;) There's JSON, and also TOML: https://github.com/mojombo/toml -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-01 18:06, Ben Laurie wrote: On 1 October 2013 01:10, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Wat? Sez who? Protobufs is code generating code. Not allowed by google style guide. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-01 22:08, Salz, Rich wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Got any documentation for this assertion? The google style guide prohibits too-clever code. protobufs and gmock is too-clever code. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Oct 1, 2013, at 12:28 PM, James A. Donald jam...@echeque.com wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Got any documentation for this assertion? The google style guide prohibits too-clever code. protobufs and gmock is too-clever code. To be blunt, you have no idea what you're talking about. I worked at Google until a short time ago; Ben Laurie still does. Both of us have written, submitted, and reviewed substantial amounts of code in the Google code base. Do you really want to continue to argue with us about what the Google Style Guide is actually understood within Google? -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Mon, Sep 30, 2013 at 1:41 AM, ianG i...@iang.org wrote: Experience suggests that asking a standards committee to do the encoding format is a disaster. I just looked at my code, which does something we call Wire, and it's 700 loc. Testing code is about a kloc I suppose. Writing reference implementations is a piece of cake. Why can't we just designate some big player to do it, and follow suit? Why argue in committee? Well, the details are important ;) If someone is particularly fond of arguing over certificate formats, ZeroMQ is trying to design one. I'm also trying to design one as well! It would be nice to consolidate efforts on an X.509 replacement, even if it's a limited capacity one. Here's the original email to the 0MQ list: http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/022975.html Here's my response: http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/023009.html -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Here's a crazy idea: instead of using one of these formats, use a human readable format that can be described by a formal grammar which is hopefully regular, context-free, or context-sensitive in a limited manner If only we could channel the late Jon Postel. Didn't you ever notice how almost all the early Arpanet/Internet standards use plain text separated by newlines, simply parsed, with a word at the front of each line that describes what is on the line? Like, for example, the header of this email message. And the SMTP exchange that delivered it to your mailbox. It makes everything so easy to debug...and extend...and understand. And it turns out to often be more compact than binary formats. Much better than binary blobs that not even their mother could love. John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-02 05:18, Jerry Leichter wrote: To be blunt, you have no idea what you're talking about. I worked at Google until a short time ago; Ben Laurie still does. Both of us have written, submitted, and reviewed substantial amounts of code in the Google code base. Do you really want to continue to argue with us about what the Google Style Guide is actually understood within Google? The google style guide, among other things, prohibits multiple direct inheritance and operator overloading, except where stl makes you do operator overloading. Thus it certainly prohibits too-clever code. The only debatable question is whether protobufs, and much of the rest of the old codebase, is too-clever code - and it certainly a lot more clever than operator overloading. Such prohibitions also would prohibit the standard template library, except that that is also grandfathered in, and prohibits atl and wtl. The style guide is designed for an average and typical programmer who is not as smart as the early google programmers. If you prohibit anything like wtl, you prohibit the best. Prohibiting programmers from using multiple inheritance is like the BBC prohibiting the world literally instead of mandating that it be used correctly. It implies that the BBC does not trust its speakers to understand the correct use of literally, and google does not trust its programmers to understand the correct use of multiple direct inheritance. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] encoding formats should not be committee'ized
On 29/09/13 16:13 PM, Jerry Leichter wrote: On Sep 26, 2013, at 7:54 PM, Phillip Hallam-Baker wrote: ...[W]ho on earth thought DER encoding was necessary or anything other than incredible stupidity?... It's standard. :-) We've been through two rounds of standard data interchange representations: 1. Network connections are slow, memory is limited and expensive, we can't afford any extra overhead. Hence DER. 2. Network connections are fast, memory is cheap, we don't have to worry about them - toss in every last feature anyone could possibly want. Hence XML. Starting from opposite extremes, committees of standards experts managed to produce results that are too complex and too difficult for anyone to get right - and which in cryptographic contexts manage to share the same problem of multiple representations that make signing such a joy. BTW, the *idea* behind DER isn't inherently bad - but the way it ended up is another story. For a comparison, look at the encodings Knuth came up with in the TeX world. Both dvi and pk files are extremely compact binary representations - but correct encoders and decoders for them are plentiful. (And it's not as if the Internet world hasn't come up with complex, difficult encodings when the need arose - see IDNA.) Experience suggests that asking a standards committee to do the encoding format is a disaster. I just looked at my code, which does something we call Wire, and it's 700 loc. Testing code is about a kloc I suppose. Writing reference implementations is a piece of cake. Why can't we just designate some big player to do it, and follow suit? Why argue in committee? iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Why can't we just designate some big player to do it, and follow suit? Why argue in committee? Well, there are Protobufs, and there is Thrift, and there is MessagePack, and there is Avro... http://www.igvita.com/2011/08/01/protocol-buffers-avro-thrift-messagepack/ ..m ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-01 04:22, Salz, Rich wrote: designate some big player to do it, and follow suit? Okay that data encoding scheme from Google protobufs or Facebook thrift. Done. We have a complie to generate C code from ASN.1 code Google has a compiler to generate C code from protobufs source The ASN.1 compiler is open source. Google's compiler is not. Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
