erty?
For now, refer to Congress of the USA, it's in Washington DC.
Hopefully, it'll be closed soon too...
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
a starting point, I would suggest 10 years.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
than nothing.
A shortage of bread has been the inspiration for a few revolutions :)
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
antics, whereas the PGP world openly
offers incompatible conventions. Which is better or worse is beyond me.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
f TLS -- to integrate
back into IP layer and replace/augment TCP directly. Back in those days
we -- they -- didn't know enough to do an integrated security protocol.
But these days we do, I'd suggest, or we know enough to give it a try.)
iang
ally, and google does not trust its
programmers to understand the correct use of multiple direct inheritance.
I often wish I had some form of static multiple inheritance in Java...
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http:/
n the competition. Not specified beforehand.
Every proposal must include its own encoding, its own crypto suite(s),
its own identity-hiding, and dollops and dollops of simplicity.
Let the games begin!
iang
___
The cryptography mailing list
cryptog
SQL, too, had that goal. 4GLs (remember them?). XML. Has it ever worked?
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
NIST change the subkey scheduling?
I don't think they did. Our Java code was submitted as part of the
competition, and it only got renamed after the competition. No crypto
changes that I recall.
iang
___
The cryptography mailing list
cr
t of end-of-lifecycle bias of hindsight.
(3) Don't accept anything without a proof reducing the security of the whole
thing down to something overdesigned in the sense of (1) or (2).
Proofs are ... good for cryptographers :) As I'm not, I can't comment
further (no
Hi Peter,
On 30/09/13 23:31 PM, Peter Fairbrother wrote:
On 26/09/13 07:52, ianG wrote:
On 26/09/13 02:24 AM, Peter Fairbrother wrote:
On 25/09/13 17:17, ianG wrote:
On 24/09/13 19:23 PM, Kelly John Rose wrote:
I have always approached that no encryption is better than bad
encryption
ASIC farms are worth nothing.
So, it seems that there is no consensus on the nature of client auth.
Therefore I'd suggest we throw the whole question open: How much auth
and which auth will be a key telling point.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
igInt
4 booleans
20 secret key packet
21 hash
22 private key packet
23 public key packet
24 hmac
40 Hello
41 Hiya
42 Go4It
43 DataPacket
44 Teardown
I don't like it, but I've never come across a better solution.
iang
___
The cryptog
On 28/09/13 22:06 PM, ianG wrote:
On 27/09/13 18:23 PM, Phillip Hallam-Baker 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?
on the choice.
(OK, we can imagine many ways to do this ... point being that if NIST
are going to tweak the SHA3 then we need to create a way for them to do
this, and have that tweaking be under the control of the submitters, not
NIST itself. In order to maintain the faith
ward secret
ciphersuites, no baked in key length limits. I think I'd also vote
for a
lot less modes and ciphers. And probably non-NIST curves while
we're at it.
Sounds like you want CurveCP?
http://curvecp.org/
Yes, EXACTLY that. Proposals
x27;s
700 loc. Testing code is about a kloc I suppose. Writing reference
implementations is a piece of cake.
Why can't we just designate some big player to do it, and follow suit?
Why argue in committee?
iang
___
The cryptograph
icates is kicked out to a higher
application layer with key-based identities established.
Adam
On Sun, Sep 29, 2013 at 10:51:26AM +0300, ianG wrote:
On 28/09/13 20:07 PM, Stephen Farrell wrote:
b) is TLS1.3 (hopefully) and maybe some extensions for earlier
versions of TLS as well
SSL
plement a kill switch with a separate parallel system? If one is
designing the hardware, then one has control over these things.
I guess then I really don't understand the threat they are trying to
address here.
Any comments from the wider audience?
iang
___
bring out the best and leave the bureaurats
fuming and powerless.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
stion...
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
On 26/09/13 02:24 AM, Peter Fairbrother wrote:
On 25/09/13 17:17, ianG wrote:
On 24/09/13 19:23 PM, Kelly John Rose wrote:
I have always approached that no encryption is better than bad
encryption, otherwise the end user will feel more secure than they
should and is more likely to share
On 26/09/13 02:32 AM, Peter Gutmann wrote:
ianG writes:
Well, defaults being defaults, we can assume most people have left it in
default mode. I suppose we could ask for research on this question, but I'm
going to guess: most.
“Software Defaults as De Facto Regulation: The Ca
On 25/09/13 21:12 PM, Jerry Leichter wrote:
On Sep 25, 2013, at 12:31 PM, ianG wrote:
...
My conclusion is: avoid all USA, Inc, providers of cryptographic products.
In favor off ... who?
Ah well, that is the sticky question. If we accept the conclusion, I
see these options:
1. shift
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, this list is about those who know how to an
security is far outweighed by the benefit
of a "good enough" security delivered to more people.
We're talking multiple orders of magnitude here. The math that counts is:
Security = Users * Protection.
iang
___
The cryptograp
4:
http://www.mail-archive.com/openssl-users@openssl.org/msg71899.html
Yeah, they are getting confused (compatibility failures) from too much
choice. Never a good idea. Take out the choice. One number. Get back
to work.
iang
___
The crypto
95 was that
Microsoft and AOL were both spending hundreds of millions of dollars
advertising the benefits to potential users. Bank America, PayPal etc
are potential allies here.
Curiously (digression), Paypal bought Skype for a secure end-to-end
solution to many of
s, was it an innocent mistake, or were they
influenced by NSA?
We don't have much solid evidence on that. But we can draw the dots,
and a reasonable judgement can fill the missing pieces in.
iang
___
The cryptography mailing list
cryptograph
Hi John,
(I think we are in agreement here, there was just one point below where
I didn't make myself clear.)
On 18/09/13 23:45 PM, John Kemp wrote:
On Sep 18, 2013, at 4:05 AM, ianG wrote:
On 17/09/13 23:52 PM, John Kemp wrote:
On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker
bout the targetting (user) and the
vulnerability (platform, etc). And they are very costly, by several
orders of magnitude more than mass surveillance.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
ook to the American people to reach a
consensus on the desired scope of U.S. intelligence activities
Good luck!
The views and opinions expressed herein are those of the author and do not
necessarily reflect those of the National Security Agency/Central Security
Service.
I serio
ion. In my work, I've generally modelled it such that the
entire system still works if one algorithm fails totally. But I don't
have a name for that approach.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.met
y have the
evidence that such extra effort is required? Remember, while you're
building this extra capability, customers aren't being protected at all,
and are less likely to be so in the future.
iang
___
The cryptography mailing list
crypt
avoid cache-timing attacks.
CHES 2013 was late August, already. Was anyone there? Any comments on
McBits?
(skimming paper reveals one gotcha -- huge keys, 64k for 2^80 security.
I'm guessing that FFT==fast fourier transform.)
iang
Slides:
http://cr.yp.to/talks/2013.06.12/slide
than poorly
audited entropy, we are a lot more secure because of them.)
Right. The more the merrier.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
On 14/09/13 18:53 PM, Peter Fairbrother wrote:
But, I wonder, where do these longer equivalent figures come from?
http://keylength.com/ (is a better repository to answer your question.)
iang
___
The cryptography mailing list
cryptography
s.org/guide/sdp/pad.html
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
opinions as to whether it is plausible, and
thinking about it, I'm on the fence.
I'd say it might be an unstudied problem -- for us. It's sounding like
an interesting EE/CS project, masters or PhD level?
If anyone has studied it, I'd bet fair money tha
cism, politics,
etc, our ability to be objective rapidly diminishes.
(I don't disagree with what is said above, I just agree we can't talk
productively at that level...)
iang
___
The cryptography mailing list
cryptography@metzdowd.
lem with
DNSSEC is it is so obviously architecturally "correct" but so
difficult to do deploy without many parties cooperating that it has
acted as an enormous tar baby.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http:/
On 9/09/13 02:16 AM, james hughes wrote:
I am honestly curious about the motivation not to choose more secure modes that
are already in the suites?
Something I wrote a bunch of years ago seems apropos, perhaps minimally
as a thought experiment:
Hypothesis #1 -- The One True Cipher Suite
nly security, perhaps mildly, but the point is that
there is precious little evidence that they have improved security.
So maybe all we want to say is that it is time for the IETF engineers to
look at the numbers, and maybe be skeptical about whether the approach
is generating security for the end us
ram to mix it [2]; as small as possible so
a room full of techies could spend no more than 10 minutes checking it
on the day [3].
The output of this was then fed into the OpenSSL script to do the root
key. (I'm interested if anyone can spot a flaw in this concept.)
iang
[0] Thi
enough leverage for intercept purposes
but make it useless as a public key system.
Thanks. This far better explains the conundrum. There is a big
difference between a conceptual public key algorithm, and one that is
actually good enough to compete with the ones we typically use.
iang
rates the best ROI. Just like
the industrialised phishing/hacking gangs that emerged in the 2000s...
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
domain owner can deliver a public key with authenticity
using the DNS. This strikes a deathblow to the CA industry. This
threat is enough for CAs to spend a significant amount of money slowing
down its development [0].
How much more obvious does it get [1] ?
iang
[0] If one is a finance
reduce the part played by public
key crypto. Wherever & whenever you can get part of the design over to
symmetric crypto, do it. Wherever & whenever you can use the natural
business relationships to reduce the need for public key crypto, do that
too!
iang
ps; http://iang.org/ssl/h2_
S starting up with its own
self-signed cert, etc, etc.
iang
[0] it depends on how you measure the 80% mark, though.
PS: More here on OODA loops
http://financialcryptography.com/mt/archives/001210.html
http://financialcryptography.com/mt/archives/001444.html
___
re
complete semantics of the public key system -- maybe that is what the
theorem assumes? But if I was the NSA I'd be happy with the compromise.
I'm good at keeping *my key secret* at least.
iang
___
The cryptography mailing list
cryptog
On 7/09/13 01:51 AM, Peter Gutmann wrote:
ianG writes:
And, controlling processes is just what the NSA does.
https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html
How does '(a) Organizations and Conferences' differ from SOP for these sorts
of things?
In pri
What is perhaps more interesting is how these tricks interplay with each
other. That's something that we'll have trouble seeing and imagining.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
majority of developers are happy to punt and just use the OS'
random numbers.
Right. If you don't care, just use what the OS provides. /dev/urandom
or CAPI or whatever. If you do care, you should implement a
collector-mixer-DRBG design yourself.
iang
__
toring all your internet purchase transactions with the
hope they can crack it later; if the FBI/NSA want your CC number they
can get it by asking.
That's what the crims do to, they ask for all the numbers, they don't
bother much with SSL.
iang
___
On 6/09/13 11:32 AM, ianG wrote:
And, controlling processes is just what the NSA does.
https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html
Oops, for those unfamiliar with CAcert's peculiar use of secure
browsing, drop the 's' in the above URL. Then it wil
less, and it's rather
easy to tip a good committee into it.
(If anyone knows of a way of breaking the logjam with TLS, let me know).
In contrast, it is not well known how to repair the damage once done.
The normal method is to abandon ship, swim away, build another ship with
1 or 2 o
tent potential, even that is not necessarily enough
but it would be a start.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
luff, designed to suck money from cow in w.DC.
Many a conman has made rich by claiming some secret invention; the
investors are the muggins for putting their money in without doing the
due diligence.
iang
___
The cryptography mailing list
cryptogra
Also, to bed in a complete understanding, a separate requirement 6.b
should be added for a second signing process using separate "signing
keys" following the notions expressed in (eg) EU digital signature
directive (eg) OpenPGP cleartext signing. However, this should be
c
es the task harder.)
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
NSA. But the NSA and the FBI and the
DEA and every local police force ... that's terrifying. That's a purer
essence of terror, far worse than terrorism. We need a new word.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
in the
email metaphor by simply adding it to chat clients, and by adding IM
technology to existing email clients. Both clients can allow us to
write emails and send them, over their known IM channels to known contacts.
Why do we need the 1980s assumption of being able to send freely to
e
f research to decide what is their best guess at
their private entropy source.
Thanks to all.
iang
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
If I have N pools of entropy (all same size X) and I pool them
together with XOR, is that as good as it gets?
My assumptions are:
* I trust no single source of Random Numbers.
* I trust at least one source of all the sources.
* no particular difficulty with lossy combination.
iang
read, so the interface is trivial.
Then, when it comes time to generate those special keys, we could
simply plug it in, run it, clean up the output in software and use
it. Hey presto, all those nasty software and theoretical
difficulties evaporate.
iang
[1] the competitive p
Ben Laurie wrote:
IanG wrote:
2. GPG + Engimail + Thunderbird. Will never be totally robust because
there is too much dependency.
What does this mean? GPG + Enigmail, whilst not the best architecture I
ever heard of, is a tiny increment to the complexity of Thunderbird.
Are you saying
YMMV. Private email for the masses
isn't really in the foreseeable future. The future is
really moving towards newer architetures, email is old and
tired. Think mobile, chat and p2p directions. But those
guys are quite incremental in their improvements, so it will
take a wh
be trusted ... is more clearly
explained in negotiation. Often, someone will state up
front that they want to find the win-win; which is a signal
that they are in the win-lose, because real win-win is about
actions not words, and word
components to the OS, and accept any failings. If doing
paranoid-level stuff, then best to implement ones own mix
and just stir in the OS level offering. That way we reduce
the surface area for lower-layer config attacks like the
Deb
This page seems to describe the security:
http://waste.sourceforge.net/security.html
iang
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
70 matches
Mail list logo
