[cryptography] Word-boundary-sensitive hashing
Suppose I have a sequence of words over some alphabet, and I want to compute a cryptographically secure hash over that. Simply concatenating the hashes to form a single word does not work because the word boundaries might have been meaningful and not implicit in the inputs, and then you have second preimages etc. I guess this is why we have DER, among other reasons. I've been asked to provide some citation for this observation, but I can't find a proper reference. Any suggestions? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PGP word list
* Werner Koch: On Sun, 22 Feb 2015 13:19, f...@deneb.enyo.de said: An option to spell out the digits and letters in a hex fingerprint would be a good start, so that you end up with some sort of Something like this? $ gpg -k --with-icao-fingerprint 1e42b367 pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] Key fingerprint = 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 Eight Zero Six One Five Eight Seven Zero Foxtrott Five Bravo Alfa Delta Six Nine Zero Three Three Three Six Eight Six Delta Zero Foxtrott Two Alfa Delta Eight Five Alfa Charlie One Echo Four Two Bravo Three Six Seven uid [ unknown] Werner Koch w...@gnupg.org Yes, this is what I had in mind. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Near-collisions and ECC public keys
On Mon, Dec 29, 2014 at 8:18 AM, Florian Weimer f...@deneb.enyo.de wrote: To check an OpenPGP fingerprint for correctness, it is sufficient (for practical purposes) to compare the leading and trailing eight hexadecimal digits, and perhaps a few digits in the middle. It is, only if you prefer these odds... 16^16/2^64 = 1.00 16^19/2^76 = 1.00 Huh? I believe collisions in the former are already well known. Producing a colliding pair isn't *that* hard (it's been done for the key ID part in V4 keys), but computing a partial 64-bit collision for a specific key is still expected to be quite expensive. (The chosen-prefix collisions for MD5 should completely break V3 certification signatures, but I don't think anything has been published yet.) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Near-collisions and ECC public keys
To check an OpenPGP fingerprint for correctness, it is sufficient (for practical purposes) to compare the leading and trailing eight hexadecimal digits, and perhaps a few digits in the middle. This is not true for raw RSA keys because weak keys are in close Hamming distance to any given reference key (I think, I haven't verified this). So you'd need to compare the full (n, e) pair, bit by bit, or compare a cryptographically strong digest of them (the OpenPGP approach, more or less). ECC public keys are small, and a digest will not provide much of a length reduction. But I wonder if the digest would still make sense to perturb the bits, so that it is not possible to create a near-collision. Do ECC public keys behave like RSA keys in this regard? Does this depend on the chosen encoding format? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] STARTTLS for HTTP
* Tom Ritter: I've been watching various efforts at widespread opportunistic encryption, like TCPINC and STARTTLS in SMTP. It's made me wonder why it isn't used for HTTP. What's the point? Anything that speaks HTTP also speaks HTTPS, so there's no need for the If you support it, I have TLS available. Just use any of multitude of redirect mechanisms for your webserver to kick people onto HTTPS. Some clients do not send SNI, so it's possible to send HTTP requests to the right server, but not HTTPS requests. You also have to go through the hassle of obtaining and renewing certificates. Here, you means the person uploading content, the server operator isn't supposed to get certificates without your explicit consent (and collecting an additional fee). If basic encryption was purely a transport layer matter (without authentication and security against active attackers), server operators could simply negotiate it with clients, just like they assign customer domains to IP addresses as they see fit today. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA Said to Exploit Heartbleed Bug for Intelligence for Years
2. Score another 1 up for interpreted languages that handle array
allocation cleanly. This is more or less a buffer overflow, in a wider
sense.
Virtually the same bug can occur (and has occurred) in memory-safe
languages due to buffer reuse.
Go was mentioned elsewhere in this thread, so let's look at how it
handles I/O:
type Reader interface {
Read(p []byte) (n int, err error)
}
http://golang.org/pkg/io/#Reader
The return value n tells the caller that the indices p[0], p[1], …,
p[n-1] contain valid data, and n can be less than the length of p. So
if the caller, during parsing, reads beyond p[n-1], but not beyond
p[len(p)-1], the language runtime will not detect this and data which
depends on where and how the buffer has been used before will be
returned.
There is still a difference: Only data that was in the buffer before
can be returned. But depending on the buffer reuse mechanism, such
data may still include bits of cleartext from unrelated connections.
Buffer reuse is a commonly employed performance optimization in
garbage-collected languages because without it, the I/O speed is
constrained by the speed at which the garbage collector can collect
buffers used only once.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] /dev/random is not robust
http://eprint.iacr.org/2013/338.pdf Isn't this straight from the crypto paper construction kit? Make up some criterion, show that a popular primitive or implementation lacks it, demonstrate that a new construction has it. Talk about the standard model. Do not provide any explicit bounds. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
On 02/10/13 at 08:51am, Florian Weimer wrote: There is widespread belief that compressing before encrypting makes cryptanalysis harder, so compression is assumed to be beneficial. Any academic references? Applied Cryptography (2nd edition) contains this: | 10.6 Compression, Encoding, And Encryption | | Using a data compression algorithm together with an encryption | algorithm makes sense for two reasons: | | Cryptanalysis relies on exploiting redundancies in the plaintext; | compressing a file brfore encryption reduces these redundancies. | | Encryption is time-consuming; compressing a file before encryption | speeds up the process. | | The important thing to remember is to compress before encryption. […] Schneier doesn't cite any references for these claims, unfortunately. Bergen and Hogan, A Chosen Plaintext Attack on an Adapative Arithmetic Coding Compression Algorithm (2002) cite Witten and Cleary, On the privacy afforded by Adaptive Text Compression (1988) and Jones, An efficient coding system for long source sequences (1981). Neither paper appears to be available on the public Internet. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
* Ben Laurie: | 10.6 Compression, Encoding, And Encryption | | Using a data compression algorithm together with an encryption | algorithm makes sense for two reasons: | | Cryptanalysis relies on exploiting redundancies in the plaintext; | compressing a file brfore encryption reduces these redundancies. Yeah. So CRIME shows us how accurate this wild claim is. And it's not even the first attack of this type. I find the application voice codecs particularly cute. The recommendation is really puzzling. With a modern cipher, compression (even if it hasn't fingerprints of its own) should never make cryptanalysis harder. With a very weak cipher, it could make a difference, but even in the mid-90s, you hopefully wouldn't use one, even after consulting Applied Cryptography (which describes quite a few of them, admittedly). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
* Lodewijk andré de la porte: 2013/9/30 Florian Weimer f...@deneb.enyo.de 3. Message integrity does not matter. 4. The security proof assumes there is only one message, ever. 3 and your paper about VOIP regard traffic analysis. I'm not sure what else 3 refers to. Certainly a known plaintext attack would negate that part of the message, but then it wasn't very encrypted in the first place, was it? Then you can of course replace part of the message, and if you have a partial plaintext you might even make it not-garbled, but then still I think you should apply mixing/scrambling before OTP'ing your plaintext. Surely that invalidates the security proof. :-) 4 regards the notion that a One-Time-Pad is only used One-Time. Sorry, not what I meant. Even if you avoid reuse of key material, it is not (provable) secure to send more than one message. I might've misunderstood the meaning of these points. I'd like to have misunderstood, then there is something to learn. I'm trying to argue out that OTP is broken according to the standards we require from generic encryption protocols such as TLS. Or that there is a large gap between the security proof and reality, making the proof rather pointless. P.S.: Why is that paper 15 pages long? I mean, really. It's just correlating input letter (in voice), where possible, with the output bandwidth and it's changes. There is widespread belief that compressing before encrypting makes cryptanalysis harder, so compression is assumed to be beneficial. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
Which leaves open the question (in my mind) as to whether to require this: Both end points must authenticate each other. Keep in mind that the client side was deliberately crippled in browsers for privacy reasons. Support used to be much better—you could transparently created a client certificate which would automatically be used for future TLS handshakes. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
* Lodewijk andré de la porte: [OTP assumptions] 1. Good source. P[i] must be independent to anything in P nor to the method to generate P. Random, you'd typically say. Fully unpredictable might be more clear (given people's unclarity about what's random). 2. No leak of P 3. Message integrity does not matter. 4. The security proof assumes there is only one message, ever. The proof is simply not correct for multiple messages, and OTP does not provide unconditional security for the multi-message case anyway. I'm really frustrated with people claiming OTP is insecure. I don't understand how it is and I cannot seem to construe any angles of attack. This attack would work against an OTP, too: Wright et al., Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversations. http://cs.unc.edu/~fabian/papers/oakland08.pdf The basic issue has recently been rediscovered in the context of HTTP(S). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Must have seemed like a good idea at the time
* James A. Donald: This not all that fatal, as the money is traceable, but it means that the financial institution needs an apparatus to reverse cell phone transactions, and that cell phone money is therefore soft on the may scale. This has been the case for giro payments for a while, and some national banking systems stipulate that *all* direct debit transactions can be rolled back for some time after the transaction. (Lines of credit automatically enforced by banking systems already take this into account, for obvious reasons.) So all this isn't as bad as it may sound. (The phone as a second factor is an endangered species, but for other reasons.) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
So, the review is not invalid. And, even when Skype changes its model, the review remains valid. There are now features that are incompatible with the design sketched in the report, such as user password recovery and call forwarding. The key management never was end-to-end, and we'd view that somewhat differently these days (I think). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
* Adam Back: If you want to claim otherwise we're gonna need some evidence. https://login.skype.com/account/password-reset-request This is impossible to implement with any real end-to-end security. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
As far as I know, Skype is e2e secure. It hasn't got end-to-end key management, so it can't be end-to-end secure against the network operator. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Validating cryptographic protocols
I've recently been asked to comment on a key exchange protocol which uses symmetric cryptography and a mutually trusted third party. The obvious recommendation is to copy the Kerberos protocol (perhaps with updated cryptographic primitives), but let's assume that's not feasible for some reason. I'm wondering what's the state of the art here, and if there are any formal methods for deciding if a particular protocol has certain security properties. I know that there have been some advances in this area, but it's sort of difficult to put together the current overall picture. (This assumes that the primitives are themselves secure, and that leakage from improper implementation of the primitives can be contained in some way, e.g. no padding oracles.) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which CA sells the most malware-signing certs?
* Peter Gutmann: I've just done a quick tally of the certs posted to http://www.ccssforum.org/malware-certificates.php, a.k.a. Digital Certificates Used by Malware. Looks like Verisign (and its sub-brand Thawte) are the malware-authors' CA of choice, selling more certs used to sign malware than all other CAs combined. GeoTrust comes second, I think all of those are Symantec brands these days. Some Microsoft developer services require Symantec code-signing certificates for transport security, so I guess there are just disproportionally many of those certificates floating around. Or is there any other reason to obtain a code signing certificate these days? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
* Ben Laurie: We're experimenting with moving openssl to git. Again. Nice. We've tried an import using cvs2git - does anyone have any views on better tools? Recently, I imported the OpenSSL repository with git cvsimport. It produced slightly corrupted results. CVS repositories as old as yours typically require manual tweaking of cvs2git because they contain traces of various CVS bugs. It might make sense to ask on the Git mailing list for help from someone who remembers previous conversions. This is not just about using the right tools, but requires rather arcane CVS knowledge. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] anyone got a how not to use OpenSSL list?
* Ryan Sleevi: Here's a quick list off the top of my head from having poked around various languages' bindings (Python, Perl, PHP, etc), from having seen various rebranded OpenSSL-using products, and from various I just want to do HTTPS Here's another one I came across: do not use the d2i_*_fp and d2i_*_bio ASN.1 decoders because they have received considerably less attention than their d2i_* cousins (which are exposed through TLS certificate parsing) and probably still have bugs. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] How to safely produce web pages from multiple sources?
* James A. Donald: How does Bob make sure his web page cannot have its secrets leaked, nor can the content that Bob intends to control be controlled by Malloc, so that Malloc cannot man-in-the-middle, cannot spy on, nor change, the conversation between Bob and Carol, cannot lead Carol to think Bob said something different from that which he intended to say, nor lead Bob to think that Carol clicked on something other than that which she clicked on? Serve the content from a different domain, possibly using an IFRAME. The browser security model is supposed to make this safe. This does not prevent semantic attacks, when users get confused about which web site they are actually using. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Devices and protocols that require PKCS 1.5 padding
* Thor Lancelot Simon: Besides PGP, what other standard, widely-deployed protocols require the use of padding types other than OAEP? DNSSEC requires PKCS#1.5 padding (if I'm not mistaken). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] can the German government read PGP and ssh traffic?
* Eugen Leitl: Unrelated, IIRC Microsoft changed the architecture of supernodes to allow for lawful interception with Skype. Skype supports transparent call forwarding, so lawful intercept is possible as well. It's just a question of how much about the interception activity leaks to the parties in a call. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Combined cipher modes
On Tue, Apr 3, 2012 at 12:02 PM, Wyss, Felix felix.w...@inin.com wrote: ... Maybe being conservative is warranted: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf don't use GCM wrong? short tags are bad. changing tag lengths are bad. use 128bit tags. If you use 128 bit tags and follow the 96 bit IV recommendation, the gains of GCM over classic AES-CBC with HMAC-MD5 or HMAC-SHA1 are somewhat limited, saving between 12 bytes or 16 bytes on per-message overhead (assuming that GCM lacks padding, which I haven't checked). 28 bytes of overhead remain. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Combined cipher modes
* Kevin W. Wall: So my first question: Are there ANY combined cipher modes for block ciphers that do not cause the ciphers to act as a key stream? (That seems to be cause most of the ones I found build the confidentiality piece around CTR mode.) If yes, please name a few (especially those with no patent restrictions). There's draft-mcgrew-aead-aes-cbc-hmac-sha1. It's expired, and there are no test vectors. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Homomorphic split-key encryption OR snake oil crypto
* Saqib Ali: Can somebody explain me how this so-called Homomorphic split-key encryption works? Isn't this just a protocal which performs a cryptographic primitive using split key material, without actually recombining the keys? (Traditional Shamir secret sharing needs a trust party for key recombination.) If yes, you might want to look for RSA Threshold Cryptography and similar work. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Homomorphic split-key encryption OR snake oil crypto
* Saqib Ali: If the system involves split key / shared secrets (m of n), then it wouldn't be a homomorphic system. Would it? I think the homomorphic part alludes to the fact that full reconstruction of the entire key is not needed to perform the cryptographic operation. In essence, I suspect it's a misnomer. We'd need a protocol description, not an interview, to be sure. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
* Werner Koch: On Wed, 15 Feb 2012 23:22, f...@deneb.enyo.de said: implementations seem to interpret it as a hard limit. The V4 key format has something which the OpenPGP specification calls an expiration date, but its not really enforceable because it can be stripped by an attacker and extended by someone who has access to the private key, by creating a new self-signature. In this sense, the The first part of your claim is wrong. The expiration date can't be stripped by an attacker because it is bound by a self-signature to the key. The self-signature is mandatory for OpenPGP keys. In that sense it is the same as with the NotAfter date in X.509. In X.509, certification signatures cover the value of the notAfter attribute. If I'm not mistaken, this is true for V3 keys as well. However, when a V4 key is signed, the certification signature does not cover the expiration date. The key holder (legitimate or not) can therefore arbitrarily extend the key life time, while keeping the key in the web of trust. This has advantages and disadvantages, of course. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
* Werner Koch: However, when a V4 key is signed, the certification signature does not cover the expiration date. The key holder (legitimate or not) can Wrong. Look at my key: :public key packet: version 4, algo 17, created 1199118275, expires 0 pkey[0]: [2048 bits] pkey[1]: [224 bits] pkey[2]: [2046 bits] pkey[3]: [2048 bits] :user ID packet: Werner Koch w...@g10code.com :signature packet: algo 17, keyid F2AD85AC1E42B367 version 4, created 1199118881, md5len 0, sigclass 0x13 digest algo 11, begin of digest 2a 29 hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 11y2d12h35m) [...] subpkt 16 len 8 (issuer key ID F2AD85AC1E42B367) The signature packet is the certification for the key and user id. A signature packet consist of subpackets which may either be hashed or unhashed. Hashed subpackets are part of the signed material and thus can't be removed. Isn't this a self-signature? I was talking about third-party signatures on the key. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Chrome to drop CRL checking
* Marcus Brinkmann: Certainly the privacy concern that Google expresses because the CA learns the IP address of users and which sites they're visiting does not extend to Google itself, which already has much more detailed information about its users. The CRL check is also done locally (but some other security checks aren't, admittedly). And someone at Symantec actually look at the OCSP logs: http://www.symantec.com/connect/blogs/more-two-billion-ocsp-lookups-single-day Unfortunately, CRLs have the same flaw as OCSP: it is impossible to recover from most CA process failures because the CRL does not actually pin down certificate contents and it is possible to have a collision with a practically irrevocable certificate. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] airgaps in CAs
* Eugen Leitl: Is anyone aware of a CA that actually maintains its signing secrets on secured, airgapped machines, with transfers batched and done purely by sneakernet? Does airgapping provide significant security benefits these days, compared to its costs? File systems are generally less robust than network stacks. USB auto-detection is somewhat difficult to control on COTS systems. So unless you build your own transfer mechanism, a single TCP port exposes less code, and code which has received more scrutiny. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] How are expired code-signing certs revoked?
* Jon Callas:
Nonrepudiation is a somewhat daft belief. Let me give a
gedankenexperiment. Suppose Alice phones up Bob and says, Hey, Bob,
I just noticed that you have a digital nature from me. Well, ummm, I
didn't do it. I have no idea how that could have happened, but it
wasn't me. Nonrepudiation is the belief that the probability that
Alice is telling the truth is less than 2^{-128}, assuming a 3K RSA
key or 256-bit ECDSA key either with SHA-256. Moreover, if that
signature was made with an ECDSA-521 bit key and SHA-512, then the
probability she's telling the truth goes down to 2^{-256}.
Those numbers aren't really important. In practice, Alice says, my
secretary signed those documents for me, without me actually knowing
their contents. This has been successfully used to dispute
commitment to content covered by digital signatures, without a
compromise at the cryptographic level (or even hinting to it).
Two factors make this a plausible defence: It is not reasonable expect
that someone legally in charge can personally witness every business
transaction (this is true even for rather small businesses), and
applicable law generally forbids use of group keys or certificates
issued to legal persons. Authorizing someone else to create
cryptographic signatures on your behalf is the only way out of this
dilemma.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Auditable CAs
* Ben Laurie: Given the recent discussion on Sovereign Keys I thought people might be interested in a related, but less ambitious, idea Adam Langley and I have been kicking around: http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf. Why wouldn't the problem we have with CAs now resurface again with the entity which maintains the log? And why is a new protocol needed? Couldn't you just treat certificates from existing browser CAs as signing requests for an uber-CA which issues traditional X.509 certificates? Viewed from another perspective, The CA must publish a list of certificates it has issued is a perfectly auditable requirement (in particular if you specify availability and format), so if this is what we want, browser vendors could just make it a requirement for being on the root list. However, this seems rather unrealistic at this point. Therefore, I have written a proposal for TLS extension which adds some additional transparency regarding the certificates which are floating around, without mandatory publication by the CAs or a third party. It relies on the phenomenon that nowadays, we have a fair number of mobile devices which migrate between networks with and without a clear path, and sufficient local storage capacity to keep track of the certificates they see. http://tools.ietf.org/html/draft-weimer-tls-previous-certificate-00 I still think the concept is sound, and some discussion in this thread (on TLS-intercepting proxies) makes it clear why the complexity of sending the entire certificate chain is necessary. (Quite deliberately, this proposal matches my first rule for evaluating improvements to the browser PKI: if more cryptography is proposed, it unlikely to work.) -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
* Adam Back: Are there really any CAs which issue sub-CA for deep packet inspection aka doing MitM and issue certs on the fly for everything going through them: gmail, hotmail, online banking etc. Such CAs do exist, but to my knowledge, they are enterprise-internal CAs which are installed on corporate devices, presumably along with other security software. Even from a vendor point of view, this additional installation step is desirable because it fits well with a per-client licensing scheme, so I'm not sure what the benefit would be to get a certificate leading to one of the public roots. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Non-governmental exploitation of crypto flaws?
* Steven Bellovin: Does anyone know of any (verifiable) examples of non-government enemies exploiting flaws in cryptography? DeCSS and subsequent DRM failures (including modchips), L0phtcrack, the IMSI catcher*, some Elcomsoft products (particularly those better than brute force), attacks on WEP, debit card skimming*, attacks on malware encryption schemes by the AV industry. All these have been productized in some form or other, which suggests that some sort of enemy exploitation exists in this context. * depending on your definition of cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
