Prev: [ANN] RefleX 0.4.0 released
Next: Exception questions
From: Thomas Pornin on 25 Mar 2010 07:25
According to Roedy Green <see_website(a)mindprod.com.invalid>:
> Someone might use the Transporter today because they can control all
> the code. JCE is a large, complex black box you are just supposed to
> trust. How do you know JCE does not contain deliberate trap doors put
> there at the insistence of the Homeland security people?

Note that I am not advocating using JCE. I deliberately cited the old
PKCS#1 padding and the RC4 stream ciphers precisely because they can be
implemented in almost no code without any interaction with JCE (less
than twenty lines for RC4, even less so for proper PKCS#1 padding).


> Your knowledge is considerably better than mine. I would have to
> research a fair bit to even understand what you are asking me to do.

The point is that publishing some crypto code without any warning about
its potential weaknesses has a high potential for being harmful. That's
the problem with cryptography: you cannot test the security. Even if it
compiles and runs, you cannot know whether it is weak or not. I suggest
adding a "warning" section on the subject.


> If you would like to fix it, I would be happy to publish it.

It is a bit problematic, partly because of possible laws on publication
and export of cryptographic material, and partly because it would make
me a kind-of competitor of the company which employs me.

Spreading the gospel, however, is no trouble, which is what I do by
pointing you to the right documents:

-- For RSA, see PKCS#1:
http://www.rsa.com/rsalabs/node.asp?id=2125
(Skip the parts on OAEP and PSS, concentrate on sections 7.2, 8.2
and 9.2.)

-- For RC4, the pseudo-code on the Wikipedia page is sufficient:
http://en.wikipedia.org/wiki/RC4


--Thomas Pornin
From: Mike Amling on 25 Mar 2010 12:20
Mike Amling wrote:
> ... generating public/private
> key pairs is must faster.

much faster.

--Mike Amling
From: Roedy Green on 26 Mar 2010 17:37
On Wed, 24 Mar 2010 20:47:42 -0500, Mike Amling <mamling(a)rmcis.com>
wrote, quoted or indirectly quoted someone who said :

>http://mindprod.com/products.html#TRANSPORTER" with no caveats about its
>weaknesses only encourages bad security.

The proper place is in the product where it could stay up date.
--
Roedy Green Canadian Mind Products
http://mindprod.com

If you tell a computer the same fact in more than one place, unless you have an automated mechanism to ensure they stay in sync, the versions of the fact will eventually get out of sync.
From: Roedy Green on 26 Mar 2010 18:23
On 25 Mar 2010 11:25:21 GMT, Thomas Pornin <pornin(a)bolet.org> wrote,
quoted or indirectly quoted someone who said :

>The point is that publishing some crypto code without any warning about
>its potential weaknesses has a high potential for being harmful. That's
>the problem with cryptography: you cannot test the security. Even if it
>compiles and runs, you cannot know whether it is weak or not. I suggest
>adding a "warning" section on the subject.

There are a number of warnings in the file transporter.use.

I have added this paragraph:

Design Philosophy

A major concern for anyone using any form of encryption is trusting
the author not to hide any trap doors in the code to snoop. He also
has to trust government and military experts not to withhold some
secret technique to crack a proffered encryption algorithm or
information about their advanced hardware abilities to crack codes
(e.G. some sort of quantum cracking). The problem is modern
cryptography is highly complex. What I have done is pare the
encryption logic down to the bone so that it would be simple enough
for the average Java programmer to understand line by line, and ensure
himself the program does exactly what it claims to. I used the
mathematically Spartan RSA algorithm. This means the program is
missing features like hybrid symmetric key, AES and chaining that
would have increased its speed and resistance to cracking. I have
also posted the source for anyone to examine. There are thus more
eyes looking for anything improper, possibly accidental. To verify my
code, you would also want to verify Java's secret key generator. If
in any way it were not secure, the whole encryption scheme would be a
house of cards. If you are a diplomat and need 100% unreachably, you
should probably not be using commercial software. Your people should
write your own one-time-pad software. The Soviets used a one-time
paper one time pad system successfully for years.

see http://mindprod.com/project/uncrackableencryption.html


--
Roedy Green Canadian Mind Products
http://mindprod.com

If you tell a computer the same fact in more than one place, unless you have an automated mechanism to ensure they stay in sync, the versions of the fact will eventually get out of sync.
From: rossum on 26 Mar 2010 18:51
On Fri, 26 Mar 2010 15:23:21 -0700, Roedy Green
<see_website(a)mindprod.com.invalid> wrote:

>He also
>has to trust government and military experts not to withhold some
>secret technique to crack a proffered encryption algorithm or
>information about their advanced hardware abilities to crack codes
>(e.G. some sort of quantum cracking).
This is not sensible. The NSA suggested changes to DES and SHA-0
which were later found to block certain attacks not publicly known at
the time, but obviously known to the NSA. Similarly GCHQ were aware
of public key cryptography before it became publicly known.

If Govenment security agencies know something they will keep it close
to their chests until it becomes publicly known.

rossum

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [ANN] RefleX 0.4.0 released
Next: Exception questions