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
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
___
The cryptography mailing list
suggest 10 years.
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
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
in 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
cryptography
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://www.metzdowd.com/mailman
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 (nor do I design to them).
iang
___
The cryptography mailing list
cryptography
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
cryptography
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
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 cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman
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
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
-forward 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 like CurveCP.
iang
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 of the result.)
iang
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
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
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman
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/TLS is a history
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 cryptography mailing list
cryptography@metzdowd.com
http
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
...
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
On 25/09/13 21:12 PM, Jerry Leichter wrote:
On Sep 25, 2013, at 12:31 PM, ianG i...@iang.org 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
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 i...@iang.org 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
of 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 cryptography mailing list
, ianG i...@iang.org 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
is, 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
cryptography@metzdowd.com
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 these problems. They never capitalised on it. Did
they ever say why?
iang
@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 cryptography mailing list
cryptography@metzdowd.com
http
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 i...@iang.org wrote:
On 17/09/13 23:52 PM, John Kemp wrote:
On Sep 17, 2013, at 2:43 PM, Phillip Hallam
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 seriously doubt that.
iang
) 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
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
cryptography@metzdowd.com
. 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.metzdowd.com
to 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/slides-djb
. 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
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 that the NSA has.
iang
/guide/sdp/pad.html
iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
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] This idea from Jon
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 users?
iang
[0] I was there in one of the committees for a decade or so (my
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
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
be 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
On 7/09/13 01:51 AM, Peter Gutmann wrote:
ianG i...@iang.org 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
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
cryptography@metzdowd.com
http://www.metzdowd.com/mailman
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
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_divide_and_conquer.html#h2.4
, then the 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
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 others.
Peter.
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 will securely load
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
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
___
The cryptography mailing
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
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
expressed in (eg) EU digital signature
directive (eg) OpenPGP cleartext signing. However, this should be
clearly stated as optional, as such digital signatures are fraught, and
if not optional, the system will fail to be implemented and be accepted.
iang
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
cryptography@metzdowd.com
http
for mortgage fraud, or any international bank
with ops in the USA. Or any company in Iran, Iraq, Syria, Afghanistan,
Pakistan, India, Palestine, or gambling companies in the
Caribbean, Gibraltar, Australia, Britain. Or any arms deal or energy deal.
(Yes, that makes the task harder.)
iang
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
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
everyone, anyway?
iang
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
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 process and a software clean-up would sort out
any quality issues
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 while.
(Yes, I know that's not the question you asked :)
iang
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
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 words in this case would lead to a
false sense of security.
iang
, 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
Debian adventure.
iang
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]
67 matches
Mail list logo
