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.
This is a
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 hal...@gmail.com 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
On Oct 10, 2013, at 11:58 AM, R. Hirschfeld r...@unipay.nl 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,
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 a...@me.com 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
On Oct 8, 2013, at 1:11 AM, Bill Frantz fra...@pwpconsult.com 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
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
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 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*
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
On Oct 7, 2013, at 1:43 AM, Peter Gutmann pgut...@cs.auckland.ac.nz 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
On Oct 7, 2013, at 11:45 AM, Arnold Reinhold a...@me.com 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
On Oct 7, 2013, at 12:45 PM, Ray Dillinger b...@sonic.net 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
On Oct 7, 2013, at 6:04 PM, Philipp Gühring p...@futureware.at 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
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 environments are
On Oct 1, 2013, at 5:34 AM, Ray Dillinger b...@sonic.net 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
On Oct 3, 2013, at 7:33 PM, Phillip Hallam-Baker hal...@gmail.com 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
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 about
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 think of any examples where SHA-128 would
On Oct 3, 2013, at 10:09 AM, Brian Gladman b...@gladman.plus.com 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
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 those
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 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.
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
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
On Sep 30, 2013, at 9:01 PM, d.nix d@comcast.net 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
On Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik di...@webweaving.org 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*.
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
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 that
On Sep 30, 2013, at 4:16 AM, ianG i...@iang.org 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
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 actual
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,
On Sep 22, 2013, at 8:09 PM, Phillip Hallam-Baker hal...@gmail.com 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
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 concerned
On Sep 24, 2013, at 6:11 PM, Gerardus Hendricks konfku...@riseup.net 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
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
The
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 ones
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 of
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
On Sep 17, 2013, at 11:54 AM, Perry E. Metzger pe...@piermont.com 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
On Sep 17, 2013, at 5:49 AM, ianG i...@iang.org 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
On Sep 17, 2013, at 6:21 PM, John Kelsey crypto@gmail.com 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
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 ... pairs of
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 theoretical
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
[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 a...@ddg.com wrote:
On Sep 11, 2013, at 12:13 , Jerry Leichter leich...@lrw.com wrote:
On Sep 11, 2013, at 9:16 AM, Andrew W
On Sep 11, 2013, at 9:16 AM, Andrew W. Donoho a...@ddg.com 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
On Sep 11, 2013, at 1:44 PM, Tim Dierks t...@dierks.org 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
On Sep 11, 2013, at 5:57 PM, Nemo n...@self-evident.org 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
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
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 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 10, 2013, at 5:49 PM, Perry E. Metzger pe...@piermont.com 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 =
On Sep 10, 2013, at 12:43 PM, Nemo n...@self-evident.org 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
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 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 be a
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 2^N
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
there
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. Blaze
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
secure
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 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, public key
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
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 without the
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 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 been the
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 subtle
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 you
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.
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) that says
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 essence of
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: In English, the distinction is way
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 from
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 secure
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.
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.
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 algorithm
[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
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
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
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
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 these
This first publication of differential cryptanalysis was at CRYPTO'90. I
highly doubt Karn analyzed his construction relative to DC. (His post
certainly makes no mention of it.)
At first glance - I certainly haven't worked this through - it should be
straightforward to construct a hash will
On Sep 4, 2013, at 10:45 AM, Faré fah...@gmail.com 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
On Sep 3, 2013, at 12:45 PM, Faré fah...@gmail.com wrote:
Don't write the code. Write a reasonably general software solver that
finds a program that fulfill given specifications, given a minimum
number of hints. Then write a specification for the problem (e.g.
finding a nice elliptic curve
On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote:
Can't you trivially transform a hash into a PRNG, a PRNG into a
cypher, and vice versa?
No.
hash-PRNG: append blocks that are digest (seed ++ counter ++ seed)
Let H(X) = SHA-512(X) || SHA-512(X)
where '||' is concatenation. Assuming
On Sep 1, 2013, at 6:06 PM, Perry E. Metzger wrote:
We know what they spec for use by the rest of the US government in
Suite B.
http://www.nsa.gov/ia/programs/suiteb_cryptography/
AES with 128-bit keys provides adequate protection for classified
information up to the SECRET level.
On Sep 1, 2013, at 10:35 PM, James A. Donald wrote:
Meanwhile, on the authentication side, Stuxnet provided evidence that the
secret community *does* have capabilities (to conduct a collision attacks)
beyond those known to the public - capabilities sufficient to produce fake
Windows
On Sep 2, 2013, at 1:25 PM, Perry E. Metzger wrote:
On Mon, 2 Sep 2013 00:06:21 -0400 Jerry Leichter leich...@lrw.com
wrote:
- To let's look at what they want for TOP SECRET. First off, RSA -
accepted for a transition period for SECRET, and then only with
2048 bit moduli, which until
Do we know they produced fake windows updates without assistance
from Microsoft?
Given the reaction from Microsoft, yes.
The Microsoft public affairs people have been demonstrating real
anger at the Flame attack in many forums.
...Clearly, as things like bad vendor drivers updates have
On Sep 1, 2013, at 2:36 AM, Peter Gutmann wrote:
John Kelsey crypto@gmail.com writes:
If I had to bet, I'd bet on bad rngs as the most likely source of a
breakthrough in decrypting lots of encrypted traffic from different sources.
If I had to bet, I'd bet on anything but the crypto.
On Sep 1, 2013, at 2:11 PM, Perry E. Metzger wrote:
On Sun, 1 Sep 2013 07:11:06 -0400 Jerry Leichter leich...@lrw.com
wrote:
Meanwhile, just what evidence do we really have that AES is
secure?
The fact that the USG likes using it, too.
We know they *say in public* that it's acceptable
On Aug 31, 2013, at 2:02 PM, Ray Dillinger wrote:
... It is both
interesting and peculiar that so little news of quantum computing has been
published since.
I don't understand this claim. Shor's work opened up a really hot new area
that both CS people and physicists (and others as well) have
So the latest Snowden data contains hints that the NSA (a) spends a great deal
of money on cracking encrypted Internet traffic; (b) recently made some kind of
a cryptanalytic breakthrough. What are we to make of this? (Obviously, this
will all be wild speculation unless Snowden leaks more
On Aug 29, 2013, at 7:00 PM, Phillip Hallam-Baker wrote:
...The code synthesis scheme I developed was an attempt to address the
scaling problem from the other end. The idea being that to build a large
system you create a very specific programming language that is targeted at
precisely that
On Aug 28, 2013, at 11:03 AM, Jonathan Thornburg wrote:
On Wed, 28 Aug 2013, Jerry Leichter wrote:
On the underlying matter of changing my public key: *Why* would I have
to change it? It's not, as today, because I've changed my ISP or employer
or some other random bit of routing
On Aug 28, 2013, at 2:04 PM, Faré wrote:
My target audience, like Perry's is people who simply can't cope with
anything more complex than an email address. For me secure mail has to look
feel and smell exactly the same as current mail. The only difference being
that sometime the secure
On Aug 28, 2013, at 4:24 AM, danimoth wrote:
On 27/08/13 at 10:05pm, Christian Huitema wrote:
Suppose, as in Bitcoin, my email address *is* my public key
You can even use some hash compression tricks so you only need 9 or 10
characters to express the address as hash of the public key.
A different take on the problem: Would something built around identify-based
encryption help here? It sounds very tempting: My email address (or any other
string - say a bitmap of a picture of me) *is* my public key. The problem is
that it requires a central server that implicitly has
On Aug 28, 2013, at 8:34 AM, Perry E. Metzger wrote:
On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter leich...@lrw.com
wrote:
It's not as if this isn't a design we have that we know works:
DNS.
Read what I said: There's a *design* that works.
I never suggested *using DNS* - either its
1 - 100 of 210 matches
Mail list logo
