Re: Session Key Negotiation
> I am designing a transport-layer encryption protocol, and obviously wish > to use as much existing knowledge as possible, in particular TLS, which > AFAICT seems to be the state of the art. In general, it's probably a good idea to look at existing mechanisms and analyze why they're not appropriate, rather than start with a clean slate and "import" things that seem useful, especially if you don't understand the rationale. /r$ -- SOA Appliance Group IBM Application Integration Middleware - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PKCS to XML?
> Is there any standard, better still existing code, for translating > keys and certificates and suchlike to and from XML? Base64-encoded DER. It's what the XML security standards all (W3C/IETF XML Digital Signature, W3C/IETF XML Encryption, W3C XKMS, OASIS WS-Security, etc.) all use. XML DSIG defines a raw public key format, but nobody uses that. > I recollect an utterly useless standard for encrypted XML I wonder what you're thinking of? The W3C/IETF XML Encryption standard is *very* good at encrypting XML. Were you thinking of that, and using it to do something else? /r$ -- SOA Appliance Group IBM Application Integration Middleware - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Chinese WAPI protocol?
Today in slashdot (http://it.slashdot.org/it/06/06/12/0710232.shtml) there was an article about China wanting to get WAPI accepted as a new wireless security standard. Has anyone looked at it? /r$ -- SOA Appliances Application Integration Middleware - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why the exponent 3 error happened:
>From http://www.w3.org/2001/tag/doc/leastPower.html : When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. This finding explores tradeoffs relating the choice of language to reusability of information. The "Rule of Least Power" suggests choosing the least powerful language suitable for a given purpose -- STSM, Senior Security Architect SOA Appliances Application Integration Middleware - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
> From a security point of view, shar has obvious > problems :-) Really, what? There are things it doesn't do, but since it's only a packaging format that's a good thing. /r$ -- STSM, Senior Security Architect SOA Appliances Application Integration Middleware - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: crypto maxims
> I have posted my ideas on defensive use of crypto here: > > https://www.subspacefield.org/security/cgi-bin/moin.py/CryptoMaxims > > This is not about cipher design, it's more about protocol design > and implementation. And the very first thing that happened is my browser complained about the SSL certificate. /r$ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why self describing data formats:
>Many protocols use some form of self describing data format, for example > ASN.1, XML, S expressions, and bencoding. I'm not sure what you're getting at. All XML and S expressions really get you is that you know how to skip past something you don't understand. This is also true for many (XER, DER, BER) but not all (PER) encodings for ASN.1. Are you saying why publish a schema? /r$ -- STSM, Senior Security Architect DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Elcomsoft trying to patent faster GPU-based password cracker
Papers are nice; working hardware is cooler:) A SHA1/MD5 brute-force cracker built from "scrapped" HD transformers: http://nsa.unaligned.org/index.php -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ITU-T recommendations for X.509v3 certificates
> I'm looking for a halfway self-contained set of ITU-T recommendations > which are relevant for implementing X.509v3 certificates. The > references in RFC 3280 appear to be incomplete; for instance, a > reference for ASN.1 itself is missing. The ITU/ISO ASN1 standards are available for free download; see http://asn1.elibel.tm.fr/standards/ > Or is it unreasonable to expect that the specs match what is actually > needed for interoperability with existing implementations (mostly in the > TLS, S/MIME area)? It's no worse than any other spec-vs-reality. You're more likely to find issues with the IETF specs layered on top of ASN1 than with ASN1 itself. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Question on export issues
In my personal experience, if you are developing a mass-market item with conventional crypto (e.g., SSL, S/MIME, etc ) then it is fairly routine to get a commodity export license which lets you sell globally. Disclaimers abound, including that I'm not a lawyer and certainly don't speak for IBM. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Question on export issues
> Is there some technology that they are so afraid of that they still > won't let it ship or does it just matter who you are, not what it is? I wouldn't know for sure, but I am sure that who is asking permission does matter. /r$, sounding like his idol dan :) -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
> SSL is layered on top of TCP, and then one layers one's > actual protocol on top of SSL, with the result that a > transaction involves a painfully large number of round > trips. Perhaps theoretically painful, but in practice this is not the case; commerce on the web is the counter-example. The benefits of layering for outweigh the perceived gains of just merging it all together into one glob. For example, the ability to replace layers, or replace them by just dropping in a new library. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
> The wider point of Peter's writeup -- and of the therapy -- is that > developers working on security tools should _know_ they're working in > a notoriously, infamously hard field where the odds are > _overwhelmingly_ against them if they choose to engineer new solutions. Developers working in almost any field should know the history and best practices -- is PGP's original "bass o matic" any more important than the code in a defibrillator? -- but this is not the way our field works right now. Compare it to something like civil engineering or architecture. Until we get to that point -- and we may never got there, nor want to -- it is probably better to act as mentors than, say, pricks. :) I thought Peter's soundwave idea was kinda funny, and hopefully lessened the sting. Guus's note should recommended reading on a regular basis. If we want to spread the use of crypto, perhaps we should be nicer to those who are also trying to do the same thing albeit poorly. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
> Thus unlike with bridges, you fundamentally can't > evaluate the quality of a security system you built if you're unfamiliar > with the state of the art of _attacks_ against security systems, and you > can't become familiar with those unless you realize that these attacks > have each brought down a system previously considered impregnable. I don't see how this invalidates my analogy. In 1940 they didn't know understand about wind-induced vibration and yet it brought down the Tacoma Narrows bridge. A few years ago we didn't know much about hash collisions, yet since then the field has brought down MD5. If the field isn't codified, all the more reason to spread knowledge rather than encourage a priesthood. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC? Crypto export restrictions
I would expect hardware designs to be treated more like hardware than software. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why doesn't Sun release the crypto module of the OpenSPARC? Crypto export restrictions
If only to make sure that there's no confusion about where I stand: I agree with you completely John. I am not surprised that the feds or Sun see it otherwise. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: voting by m of n digital signature?
> Is there a way of constructing a digital signature so > that the signature proves that at least m possessors of > secret keys corresponding to n public keys signed, for n > a dozen or less, without revealing how many more than m, > or which ones signed? Yes there are a number of ways. Usually they involve splitting the private key so that when a quorum of fragment signatures are done, they can be combined and the result verified by the public key. Look for multi-step signing or threshold signatures, for example. Disclaimer: I worked at CertCo who had the "best" technology in this area. It was created for SET. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Unattended reboots (was Re: The clouds are not random enough)
> in order for the application to have access to the keys in > the crypto hardware upon an unattended reboot, the PINs to the hardware > must be accessible to the application. The cards that I know about work differently -- you configure them to allow unattended reboot, and then no PIN is involved. This is a little more secure, in that it requires a conscious decision to do this, as opposed to sticking the PIN somewhere on the filesystem. /r$ -- STSM, DataPower CTO WebSphere Appliance Architect http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Unattended reboots (was Re: The clouds are not random enough)
> All the HSMs I've worked with start their system daemons automatically; > but the applications using them must still authenticate themselves to > the HSM before keys can be used. How do the cards you've worked with > authenticate the application if no PINs are involved? Sorry, I wasn't clear enough. When I think PIN I think of a keypad and secure channel to the HSM. Not the name/password used by the application. For that, of course, you're right -- the application needs it. /r$ -- STSM, DataPower CTO WebSphere Appliance Architect http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: a crypto puzzle about digital signatures and future compatibility
> This at least suggests that the v1.7 readers need to check *all* > hashes that are offered and raise an alarm if some verify and others > don't. Is that good enough? Isn't that what SSL/TLS does? /r$ -- STSM, DataPower CTO WebSphere Appliance Architect http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: US crypto/munitions again?
> http://www.ddj.com/linux-open-source/220800130 Status quo. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Intel to also add RNG
> Have they forgotten the enormous amount of suspicion last time they > tried this? More likely they're expecting everyone else to have forgotten about being suspicious. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Persisting /dev/random state across reboots
At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or "shrug, whatever" idea? I suppose the idea is that "all startup procs look the same" ? tnx. -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
> (In a threshold cryptosystem, the shares would be used in a protocol to > perform the desired cryptographic operation [e.g., signing] without ever > reconstructing the real secret.) Has real threshold cryptography never > been used anywhere? Yes, the root key for the SET consortium was done this way. The technology was developed by Banker's Trust Electronic Commerce, which was spun off into a company called CertCo. They also had a method of re-splitting a key; think of a trade group that votes out one of the members without that entity's consent. The code to do all that was on the HSM cards. Both techniques are patented. CertCo failed and I don't know who ended up with the IP. (As a souvenir from the wind-down, I have a co-branded CertCo/Chrysalis HSM. :) /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
> Also, note that HSTS is presently specific to HTTP. One could imagine > expressing a more generic "STS" policy for an entire site A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Look at the "tlsnextprotonec" IETF draft, the Google involvement in SPDY, and perhaps this message as a jumping-off point for both: http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY I was happy to see that the interest is in piggy-backing, not in changing SSL/TLS. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
(For what it's worth, I find your style of monocase and ellipses so incredibly difficult to read that I usually delete your postings unread.) > as previously mentioned, somewhere back behind everything else ... there > is strong financial motivation in the sale of the SSL domain name digital > certificates. I don't doubt that this was true when it was the secure sockets layer and "e-commerce on the web" were just starting up. But I don't think it's accurate any longer. Or rather, who cares how VRSN wants to make money? :) Verisign owns a large portion of the CA market; their market-cap is US$5B. Google's is US$143B, Apple's is US$220B and Microsoft's is US$206B. I mention Google because they are very involved and influential in Internet infrastructure, and Apple because many believe they will be dominant content delivery system, and Microsoft because they were a sponsor of the original SDSI research ( http://people.csail.mit.edu/rivest/sdsi10.html) If someone has a better mousetrap, there's several places that can make it happen and swallow 44% of the SSL market ( https://press.verisign.com/easyir/customrel.do?easyirid=AFC0FF0DB5C560D3&version=live&prid=631314&releasejsp=custom_97 ) with nary a burp. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [Cryptography] Snowden "fabricated digital keys" to get access to NSA servers?
> How could it be arranged that "if anything happens at all to Edward > Snowden, he told me he has arranged for them to get access to the full > archives"? A lawyer or other (paid) confidant was given instructions that would disclose the key. "Do this if something happens to me." It doesn't have to be an on-line mechanism. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Good private email
I don't think you need all that much to get good secure private email. You need a client that can make PEM pretty seamless; reduce it to a button that says "encrypt when possible." You need the client to be able to generate a keypair, upload the public half, and pull down (seamlessly) recipient public keys. You need a server to store and return those keys. You need an installed base to kickstart the network effect. Who has that? Apple certainly; Microsoft could; Google perhaps (although not reading email is against their business model). Maybe even the FB API. It's not perfect -- seems to me the biggest weakness is (a) the client could double-encrypt for TLA's to read, or (b) it could give you the wrong key so your mail only goes to the bad guy -- but it's a hell of a lot better than we have now and I'd say it's more than good enough. Thoughts? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
> This is everything *but* PRISM-proof I wasn't trying to be PRISM proof, hence my subject line. The client and keyserver could help thwart traffic analysis by returning a few "extra" keys on each request. The client then sends a structure message to some of those keys that the receiving client recognizes and ignores. > and your directory server containing public keys could very well be forced > by a law enforcement agency ( in the best case scenario because it could > also be the mafia) to answer the fbi/mafia public key on any request made to So what? Your content might get sent to the wrong person, but that can be avoided with that old PKI favorite, out of band verification. If it's necessary. > [bitcoin] has the user base No it doesn't. Not by orders of magnitude compared to the few I mentioned. Nor does it have a mail client last I checked. (I guess Chrome doesn't either, but that could be fixed with a couple of quick, and silent, updates.) > you just described PGP universal I never said it was new. The combination of size of the populace using an out of the box mail client that has this happen seamlessly, however, would be new. > Traffic analysis is the problem Do you really think that for most people on the planet, that it is? Hey folks, go off and design your perfect secure system. Build a prototype or alpha-test even. And then watch while the millions of people who could benefit from private email, and the few who could use it as an infrastructure to build more services, ignore you. Sigh. /r$ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
> ITAR doesn't require a license or permit for strong hash functions, but for > US persons > require(d?) notification of NSA of authorship, contact email and download > URL(s), at least in > 2006 it did. That strikes me as an overly-conservative reading of the rules, but it's been some time since I was involved in this stuff. After all, there is no key in a hash function. Notification was required for open source, or a commodity classification for a product that had general encryption facilities. If the notification for hash is (still?) required, I believe you can do it now via a simple phone call. To anyone. #thanks_prism. /r$ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
I still think you are reading it too conservatively. The NSA page defers the actual rules to somewhere else: "Certain commercial IA and IA-enabled IT products that contain cryptography and the technical data regarding them are subject to Federal Government export controls" Suite B includes algorithms (encryption) that are definitely export-controlled. Most think it also contains algorithms that are NOT export-controlled (digest). A Suite B implementation, which would include encryption, is controlled. A partial implementation, such as only the digests.. not proven. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
