On Oct 13, 2013, at 1:04 PM, Ray Dillinger wrote:
>>> This is despite meeting (for some inscrutable definition of "meeting")
>>> FIPS 140-2 Level 2 and Common Criteria standards. These standards
>>> require steps that were clearly not done here. Yet, validation
>>> certificates were issued.
>
>>
On Oct 11, 2013, at 11:09 PM, James A. Donald wrote:
>> Right now we've got a TCP startup, and a TLS startup. It's pretty messy.
>> Adding another startup inside isn't likely to gain popularity.
>
> The problem is that layering creates round trips, and as cpus get ever
> faster, and pipes ever
On Oct 11, 2013, at 11:26 AM, Phillip Hallam-Baker wrote:
> Quick question, anyone got a good scheme for key stretching?
>
> I have this scheme for managing private keys that involves storing them as
> encrypted PKCS#8 blobs in the cloud.
>
> AES128 seems a little on the weak side for this but
On Oct 10, 2013, at 11:58 AM, "R. Hirschfeld" wrote:
> Very silly but trivial to "implement" so I went ahead and did so:
>
> To send a prism-proof email, encrypt it for your recipient and send it
> to irrefrangi...@mail.unipay.nl
Nice! I like it.
A couple of comments:
1. Obviously, this h
On Oct 8, 2013, at 6:10 PM, Arnold Reinhold wrote:
>
> On Oct 7, 2013, at 12:55 PM, Jerry Leichter wrote:
>
>> On Oct 7, 2013, at 11:45 AM, Arnold Reinhold wrote:
>>> If we are going to always use a construction like AES(KDF(key)), as Nico
>>> suggests, why
The article is about security in the large, not cryptography specifically, but
http://www.eweek.com/security/enterprises-apply-wrong-policies-when-blocking-cloud-sites-says-study.html
points out that many companies think that they are increasing their security
by blocking access to sites they co
On Oct 8, 2013, at 1:11 AM, Bill Frantz wrote:
>> If we can't select ciphersuites that we are sure we will always be
>> comfortable with (for at least some forseeable lifetime) then we urgently
>> need the ability to *stop* using them at some point. The examples of MD5
>> and RC4 make that pre
On Oct 7, 2013, at 6:04 PM, "Philipp Gühring" wrote:
>> it makes no sense for a hash function: If the attacker can specify
>> something about the input, he ... knows something about the input!
> Yes, but since it's standardized, it's public knowledge, and just knowing
> the padding does not giv
On Oct 7, 2013, at 12:45 PM, Ray Dillinger wrote:
> Can we do anything ...[to make it possible to remove old algorithms]? If the
> protocol allows correction (particularly remote or automated correction) of
> an entity using a weak crypto primitive, that opens up a whole new set of
> attacks on
On Oct 7, 2013, at 11:45 AM, Arnold Reinhold wrote:
> If we are going to always use a construction like AES(KDF(key)), as Nico
> suggests, why not go further and use a KDF with variable length output like
> Keccak to replace the AES key schedule? And instead of making provisions to
> drop in a
On Oct 7, 2013, at 1:43 AM, Peter Gutmann wrote:
> Given the recent debate about security levels for different key sizes, the
> following paper by Lenstra, Kleinjung, and Thome may be of interest:
>
> "Universal security from bits and mips to pools, lakes and beyond"
> http://eprint.iacr.org/20
On Oct 6, 2013, at 11:41 PM, John Kelsey wrote:
> ...They're making this argument by pointing out that you could simply stick
> the fixed extra padding bits on the end of a message you processed with the
> original Keccak spec, and you would get the same result as what they are
> doing. So if t
On Oct 5, 2013, at 9:29 PM, John Kelsey wrote:
> One thing that seems clear to me: When you talk about algorithm flexibility
> in a protocol or product, most people think you are talking about the ability
> to add algorithms. Really, you are talking more about the ability to
> *remove* algorit
On Oct 5, 2013, at 6:12 PM, Ben Laurie wrote:
> I have to take issue with this:
>
> "The security is not reduced by adding these suffixes, as this is only
> restricting the input space compared to the original Keccak. If there
> is no security problem on Keccak(M), there is no security problem on
On Oct 5, 2013, at 2:00 PM, John Gilmore wrote:
>> b. There are low-end environments where performance really does
>> matter. Those often have rather different properties than other
>> environments--for example, RAM or ROM (for program code and S-boxes)
>> may be at a premium.
>
> Such environme
On Oct 5, 2013, at 11:54 AM, radi...@gmail.com wrote:
> Jerry Leichter wrote:
>> Currently we have SHA-128 and SHA-256, >but exactly why one should choose
>> one or >the other has never been clear - SHA-256 is >somewhat more
>> expensive, but I can't >thin
On Oct 4, 2013, at 12:20 PM, Ray Dillinger wrote:
> So, it seems that instead of AES256(key) the cipher in practice should be
> AES256(SHA256(key)).
>
> Is it not the case that (assuming SHA256 is not broken) this defines a cipher
> effectively immune to the related-key attack?
Yes, but think abo
On Oct 3, 2013, at 7:33 PM, Phillip Hallam-Baker wrote:
> XML was not intended to be easy to read, it was designed to be less painful
> to work with than SGML, that is all
More to the point, it was designed to be a *markup* format. The markup is
metadata describing various semantic attribut
On Oct 1, 2013, at 5:34 AM, Ray Dillinger wrote:
> What I don't understand here is why the process of selecting a standard
> algorithm for cryptographic primitives is so highly focused on speed.
If you're going to choose a single standard cryptographic algorithm, you have
to consider all the pl
On Oct 3, 2013, at 12:21 PM, Jerry Leichter wrote:
> As *practical attacks today*, these are of no interest - related key attacks
> only apply in rather unrealistic scenarios, even a 2^119 strength is way
> beyond any realistic attack, and no one would use a reduced-round version of
On Oct 3, 2013, at 10:09 AM, Brian Gladman wrote:
>> Leaving aside the question of whether anyone "weakened" it, is it
>> true that AES-256 provides comparable security to AES-128?
>
> I may be wrong about this, but if you are talking about the theoretical
> strength of AES-256, then I am not awa
On Oct 2, 2013, at 10:46 AM, Viktor Dukhovni 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 progra
On Oct 1, 2013, at 5:58 PM, Peter Fairbrother wrote:
> [and why doesn't AES-256 have 256-bit blocks???]
Because there's no security advantage, but a practical disadvantage.
When blocks are small enough, the birthday paradox may imply repeated blocks
after too short a time to be comfortable. Whet
On Oct 1, 2013, at 5:10 PM, Jeffrey Schiller wrote:
> A friend of mine who used to build submarines once told me that the first
> time the sub is submerged, the folks who built it are on board. :-)
Indeed. A friend served on nuclear subs; I heard about that practice from him.
(The same practice
On Oct 1, 2013, at 12:27 PM, Dirk-Willem van Gulik wrote:
>> It's clear what "10x stronger than needed" means for a support beam: We're
>> pretty good at modeling the forces on a beam and we know how strong beams of
>> given sizes are.
> Actually - do we ? I picked this example as it is one of
On Oct 1, 2013, at 4:13 PM, Peter Fairbrother wrote:
> And as to passwords being near end-of-life? Rubbish. Keep the password
> database secure, give the user a username and only three password attempts,
> and all your GPUs and ASIC farms are worth nothing.
Yup.
I've (half-)jokingly suggested th
On Oct 1, 2013, at 12:28 PM, "James A. Donald" 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 googl
On Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik wrote:
> ...I do note that in crypto (possibly driven by the perceived expense of too
> many bits) we tend to very carefully observe the various bit lengths found in
> 800-78-3, 800-131A , etc etc. And rarely go much beyond it*.
>
> While in a l
On Sep 30, 2013, at 9:01 PM, "d.nix" wrote:
> It's also worth pointing out that common browser ad blocking / script
> blocking / and site redirection add-on's and plugins (NoScript,
> AdBlockPlus, Ghostery, etc...) can interfere with the identification
> image display. My bank uses this sort of te
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
On Sep 30, 2013, at 4:16 AM, ianG wrote:
> I'm not really understanding the need for checksums on keys. I can sort of
> see the battlefield requirement that comms equipment that is stolen can't
> then be utilized in either a direct sense (listening in) or re-sold to some
> other theater.
I'm *
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, memo
On Sep 28, 2013, at 3:06 PM, ianG wrote:
>> Problem with the NSA is that its Jekyll and Hyde. There is the good side
>> trying to improve security and the dark side trying to break it. Which
>> side did the push for EC come from?
> What's in Suite A? Will probably illuminate that question...
The a
On Sep 25, 2013, at 12:31 PM, ianG wrote:
> Hi Jerry,
>
> I appreciate the devil's advocate approach here, it has helped to get my
> thoughts in order! Thanks!
:-)
> My conclusion is: avoid all USA, Inc, providers of cryptographic products.
In favor off ... who?
We already know that GCHQ is
On Sep 24, 2013, at 6:11 PM, Gerardus Hendricks wrote:
> I'm assuming you're talking about DUAL_EC_DBRG. ... According to the
> researchers from Microsoft, exploiting this would require
> at most 32 bytes of the PRNG output to reveal the internal state, thus
> revealing all random numbers generat
On Sep 24, 2013, at 7:53 PM, Phillip Hallam-Baker wrote:
> There are three ways a RNG can fail
>
> 1) Insufficient randomness in the input
> 2) Losing randomness as a result of the random transformation
> 3) Leaking bits through an intentional or unintentional side channel
>
> What I was concerne
On Sep 23, 2013, at 4:20 AM, ianG wrote:
>>> RSA today declared its own BSAFE toolkit and all versions of its
>>> Data Protection Manager insecure...
>
> Etc. Yes, we expect the company to declare itself near white, and the press
> to declare it blacker than the ace of spaces.
>
> Meanwhile, t
On Sep 22, 2013, at 8:09 PM, Phillip Hallam-Baker wrote:
> I was thinking about this and it occurred to me that it is fairly easy to get
> a public SSL server to provide a client with a session key - just ask to
> start a session.
>
> Which suggests that maybe the backdoor [for an NSA-spiked ra
On Sep 22, 2013, at 7:56 PM, d.nix wrote:
> ...If for example, the paper regarding manipulating the RNG circuit by
> alternate chip doping is valid, then an adversary with deep pockets
> and vast resources might well be able remotely target specific systems
> on demand. Possibly even air gapped one
On Sep 21, 2013, at 10:05 PM, d.nix wrote:
> Hah hah hah. Uh, reading between the lines, color me *skeptical* that
> this is really what it claims to be, given the current understanding
> of things...
>
> http://www.intel.com/content/www/us/en/enterprise-security/what-is-vpro-technology-video.html
On Sep 20, 2013, at 2:08 PM, Ray Dillinger wrote:
> More fuel for the fire...
>
> http://rt.com/usa/nsa-weak-cryptography-rsa-110/
>
> RSA today declared its own BSAFE toolkit and all versions of its
> Data Protection Manager insecure, recommending that all customers
> immediately discontinue use
A level beyond marketing talk, but nowhere near technical detail. Still a bit
more than has been previously described. Links to some perhap
http://www.quora.com/Apple-Secure-Enclave/What-is-Apple%E2%80%99s-new-Secure-Enclave-and-why-is-it-important
There's a link to an ARM site with a reasonabl
On Sep 17, 2013, at 6:21 PM, John Kelsey wrote:
>> I confess I'm not sure what the current state of research is on MAC
>> then Encrypt vs. Encrypt then MAC -- you may want to check on that.
>
> Encrypt then MAC has a couple of big advantages centering around the idea
> that you don't have to wor
On Sep 17, 2013, at 5:31 PM, Viktor Dukhovni wrote:
> ...And indeed the FUD around the NIST EC curves is rather unfortunate.
> Is secp256r1 better or worse than 1024-bit EDH?
Given our state of knowledge both of the mathematics, and of games NSA has been
playing, I don't believe anyone can give a
On Sep 17, 2013, at 5:49 AM, ianG wrote:
>>
>> I wish there was a term for this sort of design in encryption systems
>> beyond just "defense in depth". AFAICT there is not such a term.
>>
>> How about the Failsafe Principle? ;)
>
> A good question. In my work, I've generally modelled it such t
On Sep 17, 2013, at 11:54 AM, "Perry E. Metzger" wrote:
> I'd like to note quite strongly that (with certain exceptions like
> RC4) the odds of wholesale failures in ciphers seem rather small
> compared to the odds of systems problems like bad random number
> generators, sabotaged accelerator hard
On Sep 16, 2013, at 6:20 PM, Bill Frantz wrote:
>> Joux's paper "Multicollisions in iterated hash functions"
>> http://www.iacr.org/archive/crypto2004/31520306/multicollisions.ps
>> shows that "finding ... r-tuples of messages that all hash to the same value
>> is not much harder than finding ...
On Sep 16, 2013, at 12:44 PM, Bill Frantz wrote:
> After Rijndael was selected as AES, someone suggested the really paranoid
> should super encrypt with all 5 finalests in the competition. Five level
> super encryption is probably overkill, but two or three levels can offer some
> real advantag
On Sep 14, 2013, at 5:38 PM, Kent Borg wrote:
>> Things like clock skew are usually nothing but squish ... not reliably
>> predictable, but also not reliably unpredictable. I'm not interested in
>> squish, and I'm not interested in speculation about things that "might" be
>> random.
>
> I see
> ...The goal is to defeat the Thompson attack -- Thompson trojans [the classic
> attack described in Ken Thompson's "On Trusting Trust" where the compiler
> inserts code into login and into itself]
Just to give credit where credit is due: Ken Thompson didn't invent this
attack, and cites th
On Sep 12, 2013, at 11:06 PM, Marcus D. Leech wrote:
> There are a class of hyper-cheap USB audio dongles with very uncomplicated
> mixer models. A small flotilla of those might get you some fault-tolerance.
> My main thought on such things relates to servers, where power consumption
> isn't re
[Perry - this is likely getting too far off-topic, but I've included the list
just in case you feel otherwise. -- J]
On Sep 12, 2013, at 12:53 AM, Andrew W. Donoho wrote:
>
> On Sep 11, 2013, at 12:13 , Jerry Leichter wrote:
>
>> On Sep 11, 2013, at 9:16 AM, "
On Sep 11, 2013, at 6:51 PM, Perry E. Metzger wrote:
> It occurs to me that specifying IVs for CBC mode in protocols
> like IPsec, TLS, etc. be generated by using a block cipher in counter
> mode and that the IVs be implicit rather than transmitted kills two
> birds with one stone.
Of course, now y
On Sep 11, 2013, at 1:22 PM, Perry E. Metzger wrote:
>> Let us consider that source of colored noise with which we are most
>> familiar: The human voice. Efforts to realistically simulate a
>> human voice have not been very successful. The most successful
>> approach has been the ransom note a
On Sep 11, 2013, at 1:53 AM, zooko wrote:
> DJB's Ed25519 takes [using message context as part of random number
> generation one step further, and makes the nonce determined *solely* by the
> message and the secret key, avoiding the PRNG part altogether:
This is not *necessarily* safe. In anoth
On Sep 11, 2013, at 5:57 PM, Nemo wrote:
>> The older literature requires that the IV be "unpredictable" (an
>> ill-defined term), but in fact if you want any kind of security proofs
>> for CBC, it must actually be random.
>
> Wrong, according to the Rogaway paper you cited. Pull up
> http://www
On Sep 11, 2013, at 1:44 PM, Tim Dierks wrote:
> When it comes to litigation or actual examination, it's been demonstrated
> again and again that people can hide behind their own definitions of terms
> that you thought were self-evident. For example, the NSA's definition of
> "target", "collect
On Sep 10, 2013, at 10:57 PM, ianG wrote:
> In a protocol I wrote with Zooko's help, we generate a random IV0 which is
> shared in the key exchange.
>
> http://www.webfunds.org/guide/sdp/sdp1.html
>
> Then, we also move the padding from the end to the beginning, fill it with a
> non-repeating l
On Sep 11, 2013, at 9:16 AM, "Andrew W. Donoho" wrote:
> Yesterday, Apple made the bold, unaudited claim that it will never save the
> fingerprint data outside of the A7 chip.
By announcing it publicly, they put themselves on the line for lawsuits and
regulatory actions all over the world if the
On Sep 10, 2013, at 7:27 PM, Nemo wrote:
>> E_0 = IV # Not transmitted
>> E_{i+1} = E(E_i XOR P_{i+1})
>
> Not sure what "not transmitted" means here. In typical CBC
> implementations, the IV is certainly transmitted...
Sure. The intent was just that the ciphertext starts with E1. IV has to
On Sep 10, 2013, at 5:45 PM, Perry E. Metzger wrote:
>> [DBRG] seemed like a really weird place to put a backdoor, because
>> it was insanely slow, and it seemed unlikely to get any significant
>> use.
> As an aside, this is just the instance we know about, partially
> because they screwed up, par
On Sep 10, 2013, at 12:43 PM, Nemo wrote:
> "GET / HTTP/1.1\r\n" is exactly 16 bytes, or one AES block. If the IV is
> sent in the clear -- which it is -- that is one plaintext-ciphertext
> pair right there for every HTTPS connection.
Phil Rogoway has a paper somewhere discussing the right way to
On Sep 10, 2013, at 5:49 PM, "Perry E. Metzger" wrote:
>> Phil Rogoway has a paper somewhere discussing the right way to
>> implement cryptographic modes and API's.
>
> It would be useful to get a URL for it.
>
>> In particular, he recommends changing the definition of CBC...to
>>
>> E_0 = E(IV
On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote:
> Steve Bellovin has made the same argument and I agree with it. Proliferation
> of cipher suites is not helpful.
>
> The point I make is that adding a strong cipher does not make you more
> secure. Only removing the option of using weak
On Sep 9, 2013, at 9:17 AM, Kent Borg wrote:
>> Which brings into the light the question: Just *why* have so many random
>> number generators proved to be so weak.
>
> Your three cases left off an important one: Not bothering to seed the PRNG at
> all. I think the Java/Android cryptographic (!
On Sep 8, 2013, at 6:49 PM, Phillip Hallam-Baker wrote:
> ...The moral is that we have to find other market reasons to use security.
> For example simplifying administration of endpoints. I do not argue like some
> do that there is no market for security so we should give up, I argue that
> ther
On Sep 8, 2013, at 8:37 PM, James A. Donald wrote:
>> Your magic key must then take any block of N bits and magically
>> produce the corresponding plaintext when any given ciphertext
>> might correspond to many, many different plaintexts depending
>> on the key
> Suppose that the mappings from
On Sep 8, 2013, at 11:41 PM, james hughes wrote:
>>> In summary, it would appear that the most viable solution is to make
>> I don't see how it's possible to make any real progress within the existing
>> cloud model, so I'm with you 100% here. (I've said the same earlier.)
> Could cloud computing
On Sep 8, 2013, at 1:53 PM, Phillip Hallam-Baker wrote:
> I was asked to provide a list of potential points of compromise by a
> concerned party. I list the following so far as possible/likely:
It's not clear to me what kinds of compromises you're considering. You've
produced a list of a number
On Sep 8, 2013, at 9:15 PM, Perry E. Metzger wrote:
>> I don't see the big worry about how hard it is to generate random
>> numbers unless:
>
> Lenstra, Heninger and others have both shown mass breaks of keys based
> on random number generator flaws in the field. Random number
> generators have b
Apparently this was just a "teaser" article. The following is apparently the
full story: http://cryptome.org/2013/09/nsa-smartphones.pdf I can't tell for
sure - it's the German original, and my German is non-existent.
-- Jerry
_
On Sep 8, 2013, at 7:16 PM, james hughes wrote:
> Let me suggest the following.
>
> With RSA, a single quiet "donation" by the site and it's done. The situation
> becomes totally passive and there is no possibility knowing what has been
> read. The system administrator could even do this withou
On Sep 8, 2013, at 3:51 PM, Perry E. Metzger wrote:
>
>> Even for one-to-one discussions, these days, people want
>> transparent movement across their hardware. If I'm in a chat
>> session on my laptop and leave the house, I'd like to be able to
>> continue on my phone. How do I hand off the con
On Sep 8, 2013, at 6:09 PM, Perry E. Metzger wrote:
> Not very surprising given everything else, but I thought I would
> forward the link. It more or less contends that the NSA has exploits
> for all major smartphones, which should not be surprising
> http://www.spiegel.de/international/world/
On Sep 8, 2013, at 1:08 PM, Jerry Leichter wrote:
> On Sep 8, 2013, at 1:06 PM, Jerry Leichter wrote:
>> There was a proposal out there based on something very much like this to
>> create tamper-evident signatures
Jonathan Katz found the paper I was thinking of -
http://eprin
On Sep 7, 2013, at 11:16 PM, Marcus D. Leech wrote:
> Jeff Schiller pointed out a little while ago that the crypto-engineering
> community have largely failed to make end-to-end encryption easy to use.
> There are reasons for that, some technical, some political, but it is
> absolutely true tha
On Sep 8, 2013, at 1:06 PM, Jerry Leichter wrote:
> There was a proposal out there based on something very much like this to
> create tamper-evident signatures. I forget the details - it was a couple of
> years ago - but the idea was that every time you sign something, you modify
>
On Sep 8, 2013, at 10:45 AM, Ray Dillinger wrote:
>> Pairwise shared secrets are just about the only thing that scales
>> worse than public key distribution by way of PGP key fingerprints on
>> business cards.
>> If we want secure crypto that can be used by everyone, with minimal
>> trust, pu
On Sep 7, 2013, at 11:45 PM, John Kelsey wrote:
> Let's suppose I design a block cipher such that, with a randomly generated
> key and 10,000 known plaintexts, I can recover that key At this point,
> what I have is a trapdoor one-way function. You generate a random key K and
> then compute
On Sep 7, 2013, at 11:06 PM, Christian Huitema wrote:
>> Pairwise shared secrets are just about the only thing that scales worse than
>> public key distribution by way of PGP key fingerprints on business cards. >
>> The equivalent of CAs in an all-symmetric world is KDCs If we want
>> sec
On Sep 7, 2013, at 7:56 PM, Perry E. Metzger wrote:
>> I'm not as yet seeing that a block cipher with a backdoor is a public
>> key system,
>
> Then read the Blaze & Feigenbaum paper I posted a link to. It makes a
> very good case for that, one that Jerry unaccountably does not seem to
> believe.
The NY Times has done a couple of reports over the last couple of months about
the incomprehensibility of hospital bills, even to those within the industry -
and the refusal of hospitals to discuss their charge rates, claiming that what
they will bill you for a treatment is "proprietary".
Clear
So I'm reading some of the recent threads here, and all of a sudden, Mail.app
warns me of a problem with a cert. I have an old, essentially unused, Yahoo
email address that came along for free when I got DSL from AT&T years ago. As
with all my email connections, I require SSL - which may be ab
On Sep 7, 2013, at 10:20 AM, Jeffrey I. Schiller wrote:
> One of the most obvious ways to compromise a cryptographic system is
> to get the keys. This is a particular risk in TLS/SSL when PFS is not
> used. Consider a large scale site (read: Google, Facebook, etc.) that
> uses SSL. The private keys
On Sep 7, 2013, at 12:31 AM, Jon Callas wrote:
>> I'm sorry, but this is just nonsense. You're starting with informal, rough
>> definitions and claiming a mathematical theorem.
>
> Actually, I'm doing the opposite. I'm starting with a theorem and arguing
> informally from there
Actually, if
On Sep 7, 2013, at 4:13 AM, Jon Callas wrote:
>> Take the plaintext and the ciphertext, and XOR them together. Does the
>> result reveal anything about the key or the painttext?
>
> It better not. That would be a break of amazing simplicity that transcends
> broken.
The question is much more s
On Sep 6, 2013, at 8:58 PM, Jon Callas wrote:
>> I've long suspected that NSA might want this kind of property for some of
>> its own systems: In some cases, it completely controls key generation and
>> distribution, so can make sure the system as fielded only uses "good" keys.
>> If the algo
Following up on my own posting:
> [The NSA] want to buy COTS because it's much cheap, and COTS is based on
> standards. So they have two contradictory constraints: They want the stuff
> they buy secure, but they want to be able to break in to exactly the same
> stuff when anyone else buys it.
A response he wrote as part of a discussion at
http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html:
Q: "Could the NSA be intercepting downloads of open-source encryption software
and silently replacing these with their own versions?"
A: (Schneier) Yes, I believe so.
On Sep 6, 2013, at 11:37 AM, John Ioannidis wrote:
> I'm a lot more worried about FDE (full disk encryption) features on modern
> disk drives, for all the obvious reasons.
>
If you're talking about the FDE features built into disk drives - I don't know
anyone who seriously trusts it. Every "sec
On Sep 6, 2013, at 10:03 AM, Perry E. Metzger wrote:
>
> Naively, one could take a picture of the dice and OCR it. However,
> one doesn't actually need to OCR the dice -- simply hashing the
> pixels from the image will have at least as much entropy if the
> position of the dice is recognizable fro
On Sep 6, 2013, at 7:28 AM, Jerry Leichter wrote:
> ...Much of what you say later in the message is that the way we are using
> symmetric-key systems (CA's and such)...
Argh! And this is why I dislike using "symmetric" and "asymmetric" to describe
cryptosystems:
>> Perhaps it's time to move away from public-key entirely! We have a classic
>> paper - Needham and Schroeder, maybe? - showing that private key can do
>> anything public key can; it's just more complicated and less efficient.
>
> Not really. The Needham-Schroeder you're thinking of is the ess
>>
>> It is probably very difficult, possibly impossible in practice, to
>> backdoor a symmetric cipher. For evidence, I direct you to this old
>> paper by Blaze, Feigenbaum and Leighton:
>>
>> http://www.crypto.com/papers/mkcs.pdf
>>
>
> There is also a theorem somewhere (I am forgetting where
>> Another interesting goal: "Shape worldwide commercial cryptography
>> marketplace to make it more tractable to advanced cryptanalytic capabilities
>> being developed by NSA/CSS." ... This makes any NSA recommendation
>> *extremely* suspect. As far as I can see, the bit push NSA is making th
On Sep 5, 2013, at 10:19 PM, Jon Callas wrote:
> I don't disagree by any means, but I've been through brittleness with both
> discrete log and RSA, and it seems like only a month ago that people were
> screeching to get off RSA over to ECC to avert the "cryptocalypse." And that
> the ostensible
The actual documents - some of which the Times published with few redactions -
are worthy of a close look, as they contain information beyond what the
reporters decided to put into the main story. For example, at
http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-aga
On Sep 5, 2013, at 7:14 PM, John Kelsey wrote:
> My broader question is, how the hell did a sysadmin in Hawaii get hold of
> something that had to be super secret? He must have been stealing files from
> some very high ranking people.
This has bothered me from the beginning. Even the first le
[This drifts from the thread topic; feel free to attach a different subject
line to it]
On Sep 5, 2013, at 4:41 PM, Perry E. Metzger wrote:
> 3) I would not be surprised if random number generator problems in a
> variety of equipment and software were not a very obvious target,
> whether those pr
On Sep 4, 2013, at 10:45 AM, Faré wrote:
>>> Can't you trivially transform a hash into a PRNG, a PRNG into a
>>> cypher, and vice versa?
>> No.
>>
>
>> Let H(X) = SHA-512(X) || SHA-512(X)
>> where '||' is concatenation. Assuming SHA-512 is a cryptographically secure
>> hash H trivially is as w
1 - 100 of 505 matches
Mail list logo
