Ralph Holz | 17 Jun 2013 14:56
Picon
Favicon

Attacks against CA system before 2008

Hi,

For my write-up, I am looking into more-or-less well-documented
incidents concerning the X.509 PKI *before 2008*.

I think I have a fairly comprehensive list from December 2008 on
(StartSSL incident, RapidSSL, Comodo 1, Comodo 2, DigiNotar etc.).

To the best of my knowledge, incidents before 2008 either received very
little publicity or are so speculatively documented that they're barely
usable for an academic write-up. Thus, any pointers would be nice.

PS: I am familiar with the works of Gutmann, Grigg, Ellison and Schneier
- I'm really looking for pointers beyond.

TIA,
Ralph

--

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
John Young | 15 Jun 2013 00:47
Picon

Cypherpunk Michael Froomkin Blog at Library of Congress

http://www.loc.gov/item/lcwa00090311
Eugen Leitl | 14 Jun 2013 09:43

Free cryptography I course (courtesy Coursera)


https://www.coursera.org/course/crypto?utm_classid=971022&utm_notid=5333944&utm_linknum=1

Cryptography I

Dan Boneh

Learn about the inner workings of cryptographic primitives and how to apply
this knowledge in real-world applications!

Workload: 5-7 hours/week 

Watch intro video

Sessions:

Jun 17th 2013 (6 weeks long)	Sign Up

Mar 25th 2013 (6 weeks long)	Sign Up

Future sessions	Add to Watchlist

About the Course

Cryptography is an indispensable tool for protecting information in computer
systems. This course explains the inner workings of cryptographic primitives
and how to correctly use them. Students will learn how to reason about the
security of cryptographic constructions and how to apply this knowledge to
real-world applications. The course begins with a detailed discussion of how
two parties who have a shared secret key can communicate securely when a
(Continue reading)

Moritz | 13 Jun 2013 18:27
Picon
Favicon
Gravatar

Potential funding for crypto-related projects

Hi,

A foundation offered me money for improving, auditing, or implementing
crypto-related software and hardware. We could probably also
fund/perform usability studies.

Any suggestions?

--Mo

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Russell Leidich | 13 Jun 2013 04:31
Picon

CTR mode limit cycle length

Not to detract from the important discussion of how best to use AES CTR mode, but I have a more basic question...

I can certainly understand why the discussion of CTR mode is considered to be boring. I assume that anyone can easily verify that testing trillions of different 128-bit counter values, even in incremental sequence, produces radically different xor masks, given a "reasonable" IV.

But what's the probability of 2 xor masks colliding? Is this just assumed to be random, i.e. compatible with a birthday attack? Has anyone done anything like a limit median iteration count before repetition (LMICBR) test or scintillating entropy test? (These are described in detail on my blogs.) The former test, which could actually be performed in useful fashion on a 128-bit space using existing computer power, would likely throw up warning signs if the cycle were too short. The latter test would potentially shrink the upper bound complexity estimate for differential (i.e. interblock) cryptanalysis.

So if, let's say, 2 in every 100 xor masks collide, then I need only store 100 encrypted blocks in order to have a good chance of finding of a matching pair (or n-tuple) of xor masks, thereby facilitating statistical cracking methods. Obviously 100 is too small. So what is the actual number, for a given counter width?

Personally, I'd prefer to rely on the predictable limit cycles of Karacell 3 (but then, I'm biased). But I'm quite open to a demonstration or whitepaper showing that CTR limit cycles are also predictable and usefully long. Or maybe I've just misunderstood how CTR works. Anyone?

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
grarpamp | 13 Jun 2013 04:15
Picon

NSA "breakthrough"

Similar quotes have floated around the net for a year or so with
perhaps the two most interesting found in the article included below.
Any pointers to earlier discussion about this in the crypto community?
Has there been any consensus as to what cryptosystem this might be
referring to? Or some reasonable real world thought on how to interpret it?

"
http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/1
By James Bamford 03.15.12

According to another top official also involved with the program, the
NSA made an enormous breakthrough several years ago in its ability to
cryptanalyze, or break, unfathomably complex encryption systems
employed by not only governments around the world but also many
average computer users in the US.
"
“They were thinking that this computing breakthrough was going to give
them the ability to crack current public encryption.”
_______________________________________________
cryptography mailing list
cryptography <at> randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Noon Silk | 13 Jun 2013 02:49
Picon
Gravatar

keyserver

so what's the go-to keyserver to look people up these days?

i've tried http://keyserver.rayservers.com/, it times out upon searching, so does http://pgp.mit.edu/

am i missing some obvious places?

--
Noon Silk
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Jeffrey Walton | 13 Jun 2013 02:41
Picon

Re: CTR mode fragility vs feedback modes (Re: New Anonymity Network for Short Messages)

On Wed, Jun 12, 2013 at 8:14 PM, Nico Williams <nico@...> wrote:
> One nice advantage that counter modes have over CBC is that they don't
> need any padding (any plaintext increase).  Whereas CBC does.
Its also seekable.

We can deal with the padding by using an encrypt-then-authenticate
scheme. But we can't seek to the last page of a big document in CBC
mode without decrypting previous blocks.

Jeff
Yuhao Huang | 12 Jun 2013 12:02
Picon
Gravatar

How to optimize modular inversion w.r.t a fixed large prime?

In Elliptic curve calculations, there are lots of modular inversions. And the prime is a fixed large number, say 256 bits.

I wonder how I can optimize this operation, right now it takes a lot of time. Can any one point me to something?
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Eugen Leitl | 11 Jun 2013 21:04

Re: [liberationtech] New Anonymity Network for Short Messages

----- Forwarded message from Sean Cassidy
<sean.a.cassidy@...> -----

Date: Tue, 11 Jun 2013 10:47:21 -0700
From: Sean Cassidy <sean.a.cassidy@...>
To: liberationtech <liberationtech@...>
Subject: Re: [liberationtech] New Anonymity Network for Short Messages
Reply-To: liberationtech <liberationtech@...>

On Tue, Jun 11, 2013 at 10:29 AM, Steve Weis <steveweis@...> wrote:
> Hi. I took a quick look while procrastinating at work and found a few
> potential issues:

Thanks for taking a look. I'll be sure to incorporate your feedback.
>
> - What's up with this hard-coded salt?

Lack of love for the text client. I should just delete that code. The
primary user interface is the HTTP endpoint.

> - Any specific reason you picked CTR?

CTR is widely recommended. Cryptography Engineering specifically recommends it.

> - Use mlock here? I don't think that will help you if you run within a guest
> VM though.
> - Buffer overflow on password input

Absolutely true.

> - Is this safe for non-terminated strings?

Gah, must have missed that in my review.

> - Why do you have this checksum if you just HMACed the ciphertext?

This checksum is an important part of DiNet. Each packet comes with a
checksum that each router uses to verify the message integrity (not
authenticate, mind you) and to make sure it hasn't seen this message
before. As each router sends every packet it hasn't seen recently to
every machine that is connected to it, it is important to not re-send
data.

> - HMAC verification is vulnerable to a timing attack. Since you're using
> CTR, it's that much easier to forge messages.

I will have to look into this in my Javascript client as well. Do you
have any recommendations?

> - There's no forward security.

I am aware. This is a feature I would love to add to the Javascript client.

>
> This is by no means comprehensive. I've only been looking at a couple files.

Thanks for looking! I appreciate the feedback.

Sean

>
>
> On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy <sean.a.cassidy@...>
> wrote:
>>
>> Hello all,
>>
>> I have created a simple anonymity network that broadcasts all messages
>> to participants so that you cannot associate chatters.
>>
>> https://bitbucket.org/scassidy/dinet
>>
>> There is a simple sample client available, but you could write your
>> own client to build your own features atop the network.
>>
>> http://projects.existentialize.com/dinet/client.html
>>
>> Please let me know if you have any comments.
>>
>> Sean
>> --
>> Too many emails? Unsubscribe, change to digest, or change password by
>> emailing moderator at companys@... or changing your
settings at
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys@... or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at
companys@... or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech

----- End forwarded message -----
--

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5
Eugen Leitl | 11 Jun 2013 13:03

Re: [ipv6hackers] opportunistic encryption in IPv6

----- Forwarded message from Jim Small <jim.small@...> -----

Date: Mon, 10 Jun 2013 23:07:21 +0000
From: Jim Small <jim.small@...>
To: IPv6 Hackers Mailing List <ipv6hackers@...>
Subject: Re: [ipv6hackers] opportunistic encryption in IPv6
Reply-To: IPv6 Hackers Mailing List <ipv6hackers@...>

Hi Eugen,

I took a quick look at this - a very interesting idea.  I see a few issues that I didn't see answers to:
* Paper references a host using MLD to join an Anycast group - but AFAIK, this is not in the standards (was a
draft that appeared to die) and not supported
* Says PKI isn't good, but then uses a form of it as part of the solution

The fundamental challenge for encryption is key distribution and management:
* How do I authenticate the intended recipient(s)?
* How do I distribute a key without letting anyone except the intended recipient(s) get it?
* How do I manage the key to periodically change it while keeping it confidential?
* How do I notify the recipient if the key was compromised or is otherwise invalid?

If this paper addressed this I missed it.  The paper seems to imply that hosts get an RSA key pair but I didn't
see how.  If I'm relying on public keys, how do I know they're legitimate?

The other challenge I see with this paper is that the "simple" endpoints must obtain a key pair, configure a
CGA, and take explicit action to opt-in to encryption.  Given the target I think this is unlikely to
succeed.  I think this is an interesting idea.  For it to have a chance of adoption I think it would have to be
transparent to the endpoints.

--Jim

> -----Original Message-----
> From: ipv6hackers-bounces@... [mailto:ipv6hackers-
> bounces@...] On Behalf Of Eugen Leitl
> Sent: Monday, June 10, 2013 9:24 AM
> To: ipv6hackers@...
> Subject: [ipv6hackers] opportunistic encryption in IPv6
> 
> 
> Any idea why opportunistic encryption for IPv6 (e.g.
> http://www.inrialpes.fr/planete/people/chneuman/OE.html ) was never
> made ready for production?
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers@...
> http://lists.si6networks.com/listinfo/ipv6hackers
_______________________________________________
Ipv6hackers mailing list
Ipv6hackers@...
http://lists.si6networks.com/listinfo/ipv6hackers

----- End forwarded message -----
--

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5

Gmane