Gleb Paharenko | 7 Apr 23:00 2010
Picon

Cryptography embargo countries

Dear colleagues.

Please could you tell if OperaMini on mobile phone, which supports SSL may be a subject of criminal prosecution for cryptography embargoe countries (e.g. Syria). List of countries I've found at:
 http://schools.becta.org.uk/upload-dir/downloads/data_encryption.doc



--
Best regards.
Gleb Pakharenko.
http://gpaharenko.livejournal.com
http://www.linkedin.com/in/gpaharenko
+380503116172

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Kevin W. Wall | 8 Apr 06:32 2010
Picon

Call to review OWASP ESAPI crypto code

The Open Web Application Security Project (OWASP) is a 501(c)(3)
not-for-profit worldwide charitable organization focused on improving
the security of application software and all of OWASP's materials are
available under a free and open source software licenses.

The next release candidate of OWASP's Enterprise Security API (ESAPI)
for Java (ESAPI-2.0-rc6) has recently been released. This is the
second complete release candidate that contains the completely revamped
symmetric encryption and the first release candidate with completed user
documentation om this regard.

Before we make an official 2.0 release, we would like the completely
redesigned symmetric encryption in ESAPI to be reviewed by professional
cryptographers or security professionals with expertise in cryptography.

It shouldn't take too much time as the code-base is really fairly small--
slightly over 3900 LOC (including comments and blank lines) or approximately
1725 non-commentary source lines.

Anyhow, if you are willing to help without charge to OWASP, you can find
more details at:
    http://www.owasp.org/index.php/Request_to_review_ESAPI_2.0_crypto

Thanks in advance to those of you who can help.
-kevin--
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
Zooko O'Whielacronx | 22 Apr 19:40 2010
Picon

Re: What's the state of the art in factorization?

On Wed, Apr 21, 2010 at 5:29 PM, Samuel Neves <sneves@...> wrote
(on the cryptography@... list):
> [2] http://www.cs.umd.edu/~jkatz/papers/dh-sigs-full.pdf

I've been looking at that one, with an eye to using it in the One
Hundred Year Cryptography project that is being sponsored by Google as
part of the Google Summer of Code (see recent discussions on the
tahoe-dev archives for April 2010 [1]).

Later I discovered this paper [2] which appears to be an improvement
on that one in terms of performance (see Table 1 in [2]) while still
having a tight reduction to the Computational Diffie-Hellman (CDH)
problem. Strangely, this paper [2] doesn't appear to have been
published anywhere except as an eprint on eprint.iacr.org. I wonder
why not. Is there something wrong with it?

I still have some major questions about the funky "hash into a curve"
part of these schemes. I'm hoping that [3] will turn out to be wrong
and a nice simple dumb efficient hack will be secure for these
particular digital signature schemes.

Of course if the newfangled schemes which reduce to a random instance
of a classic hard problem work out, that would provide an even
stronger assurance of long-term safety than the ones that reduce to
CDH. See for example the paper [4] that I mentioned previously on the
cryptography@... mailing list. Unless I misunderstand, if you
can break that scheme by learning someone's plaintext without knowing
their private key, then you've also proven that P=NP!

Unfortunately that one in particular doesn't provide digital
signatures, only public key encryption, and what I most need for the
One Hundred Year Cryptography project is digital signatures.

Regards,

Zooko

[1] http://allmydata.org/pipermail/tahoe-dev/2010-April/date.html
[2] http://eprint.iacr.org/2007/019
[3] http://eprint.iacr.org/2009/340
[4] http://eprint.iacr.org/2009/576
Zooko O'Whielacronx | 22 Apr 20:18 2010
Picon

What's the state of the art in digital signatures? Re: What's the state of the art in factorization?

By the way, the general idea of One Hundred Year Security as far as
digital signatures go would be to combine digital signature
algorithms. Take one algorithm which is bog standard, such as ECDSA
over NIST secp256r1 and another which has strong security properties
and which is very different from ECDSA. Signing is simply generating a
signature over the message using each algorithm in parallel.
Signatures consist of both of the signatures of the two algorithms.
Verifying consists of checking both signatures and rejecting if either
one is wrong.

Since the digital signature algorithms that we've been discussing such
as [1] are related to discrete log/Diffie-Hellman and since an
efficient implementation would probably be in elliptic curves, then
those are not great candidates to pair with ECDSA in this combiner
scheme.

Unfortunately I haven't stumbled on a digital signature scheme which
has good properties (efficiency, simplicity, ease of implementation)
and which is based on substantially different ideas and which isn't
currently under patent protection (therefore excluding NTRUSign).

Any ideas?

[1] http://eprint.iacr.org/2007/019

Regards,

Zooko
Jonathan Katz | 23 Apr 04:18 2010
Picon

Re: What's the state of the art in factorization?

On Thu, 22 Apr 2010, Zooko O'Whielacronx wrote:

> On Wed, Apr 21, 2010 at 5:29 PM, Samuel Neves <sneves@...> wrote
> (on the cryptography@... list):
>> [2] http://www.cs.umd.edu/~jkatz/papers/dh-sigs-full.pdf

As one of the authors of the above paper, I have an obvious interest in 
this thread. =)

> Later I discovered this paper [2] which appears to be an improvement
> on that one in terms of performance (see Table 1 in [2]) while still
> having a tight reduction to the Computational Diffie-Hellman (CDH)
> problem. Strangely, this paper [2] doesn't appear to have been
> published anywhere except as an eprint on eprint.iacr.org. I wonder
> why not. Is there something wrong with it?

While I don't know of any attack, the proof of security does not appear to 
be correct.

On the other hand, there is one published scheme that gives a slight 
improvement to our paper (it has fewer on-line computations): it is a 
paper by Chevallier-Mames in Crypto 2005 titled "An Efficient CDH-Based 
Signature Scheme with a Tight Security Reduction".
Paul Crowley | 23 Apr 11:57 2010

Re: What's the state of the art in factorization?

Jonathan Katz wrote:
>>> [2] http://www.cs.umd.edu/~jkatz/papers/dh-sigs-full.pdf

> On the other hand, there is one published scheme that gives a slight 
> improvement to our paper (it has fewer on-line computations): it is a 
> paper by Chevallier-Mames in Crypto 2005 titled "An Efficient CDH-Based 
> Signature Scheme with a Tight Security Reduction".

My preferred signature scheme is the second, DDH-based one in the linked 
paper, since it produces shorter signatures - are there any proposals 
which improve on that?

Incidentally, the paper doesn't note this but that second scheme has a 
non-tight reduction to the discrete log problem in exactly the way that 
Schnorr does.
--

-- 
   __
\/ o\ Paul Crowley, paul@...
/\__/ http://www.ciphergoth.org/
Zooko O'Whielacronx | 23 Apr 15:33 2010
Picon

Re: What's the state of the art in factorization?

On Fri, Apr 23, 2010 at 3:57 AM, Paul Crowley <paul@...> wrote:
>
> My preferred signature scheme is the second, DDH-based one in the linked
> paper, since it produces shorter signatures - are there any proposals which
> improve on that?

http://eprint.iacr.org/2007/019

Has one. Caveat lector.

Regards,

Zooko
James A. Donald | 24 Apr 03:48 2010

Re: What's the state of the art in factorization?

 > Jonathan Katz wrote:
 >>>> [2] http://www.cs.umd.edu/~jkatz/papers/dh-sigs-full.pdf

 >> On the other hand, there is one published scheme that
 >> gives a slight improvement to our paper (it has fewer
 >> on-line computations): it is a paper by Chevallier-Mames
 >> in Crypto 2005 titled "An Efficient CDH-Based Signature
 >> Scheme with a Tight Security Reduction".

On 2010-04-23 7:57 PM, Paul Crowley wrote:
 > My preferred signature scheme is the second, DDH-based one
 > in the linked paper, since it produces shorter signatures -
 > are there any proposals which improve on that?

If you want shorter signatures, the proposed scheme does not
beat the Boneh, Lynn and Shacham proposal  "Short Signatures
from the Weil Pairing", which the Chevallier-Mames  paper
mentions and cites.
Paul Crowley | 24 Apr 08:20 2010

Re: What's the state of the art in factorization?

James A. Donald wrote:
> If you want shorter signatures, the proposed scheme does not
> beat the Boneh, Lynn and Shacham proposal  "Short Signatures
> from the Weil Pairing", which the Chevallier-Mames  paper
> mentions and cites.

Sure, but that depends on the existence of GDH groups, which seems a 
little less conservative than the assumption that DDH is hard in Z*_p or 
in for example a NIST elliptic curve.
--

-- 
   __
\/ o\ Paul Crowley
/\__/ www.ciphergoth.org
coderman | 26 Apr 09:37 2010
Picon

Re: What's the state of the art in digital signatures? Re: What's the state of the art in factorization?

On Thu, Apr 22, 2010 at 11:18 AM, Zooko O'Whielacronx
<zookog@...> wrote:
> By the way, the general idea of One Hundred Year Security as far as
> digital signatures go would be to combine digital signature
> algorithms. Take one algorithm which is bog standard, such as ECDSA
> ... and another which has strong security properties
> and which is very different from ECDSA. ...
>
> Unfortunately I haven't stumbled on a digital signature scheme which
> has good properties...

try McEliece cryptosystem with QC-LDPC coding or other improved and
hardened variant that suites your purposes.

one caveat - a cryptographically strong, very plentiful hardware
entropy source is required for any kind of usable key generation. but
we all have those embedded on our processor die now, right? ... :P

another benefit McEliece QC-LDPC can be made very fast on modern cores
and GPU kernels.

Gmane