Re: My little something...

Tom St Denis wrote:
Where did you get a 1024 bit curve?
From my head. :)
Where it should remain.

You are always so polite Tom. Thank you from that.


ECC is an older field than Twofish or AES designs are [AES is based off
a 1995 Ph.D. dissertation]. Your logic escapes me.

So? Its younger than RSA/Elgamal.


Even suppose there is an attack on ECC, why do you assume it will be a
sqrt/sqrt attack? If it goes sub-exp you could see 1024-bit ECC being
much weaker than 256-bits.

Its more unlikely that attack on 1024 ECC to subvert it to weaker than 256bits will happen in the near future. However, concidering the theoretical attacks against RSA and factoring, they can happen sooner.


Two ciphers in different modes with different, independend keys.

And this is supposed to be more secure or just harder to implement
correctly?

More secure ofcourse.
Dont give BS about two cascading ciphers not neccessarely being more secure or infact that they, in THEORY can be even insecure. In practice two different ciphers with two different keys are always more secure than one cipher.


Why do you assume that breaks will be so predictable. What if the
break is that there is a correlation between halves of the output?

Why do you assume breaks will not be so predictable. What if the break is not that there is a correlation between halves of the outpu?


Then the XOR would no more entropy than just one of the halves.

Actually no.


If Whirlpool is a secure hash than truncation MUST BE just as secure as
XOR'ing the halves. Otherwise all bets are n off.

Lets assume that Whirlpool produces bad, nonrandom hash of
1010137490 and we simply cut "half off" the output, so we get
10101 as hash. Now, thats bad, you can clearly see that. BUT, if we instead split it in two halves and XOR them, we get 47591 which is clearly better.

Even if half of the output is bad, it does not matter really if we XOR halves together, since the "good half" moves it randomness to the "bad half". If we just cut off some of the hash, we cut off both "bad" and "good" parts of the hash, leaving about 50% of bad and 50% of good hash anyway.


Also do you plan on encrypting 2^256 files per password?
?

You don't need a 512-bit salt unless you plan to use your password
2^256 times.

And in theory Enigma was a great piece of equipment...


To get random numbers for ciphers. I dont want to end up in situation
where only one PRNG is used and then after few years we know it has
actually been broken or is otherwise bad PRNG. Combine few different
PRNG:s and failure in one or two does not compromise security.

This is nonsense. If anything your seeding data will be the source of
the compromise not the PRNG. Using multiple PRNGs from the same bad
entropy source is not going to make it more secure.

Different PRNG:s use different entropy sources and in different ways. And again, since their output is XORed together, attacker cannot get information about what data was inputted to them, since even ONE good PRNG in that list will be enought to make the output "random" and therefore something that attacker cannot get any information about it and about the information PRNG used to get that data.


If you want to upgrade PGP start with existing protocols. Integrate
GF(p) ECC into it and start using the Whirlpool and SHA-2 series
hashes.

That is true. However, PGP does not use "sufficient" PRNG:s and it does not have cascaded ciphers possibility. Ofcourse, they could be "added" to it but...


What if I told you for the next decade you can easily protect secrets
with an 80-bit symmetric key? Would that blow your mind?

No, because that is BS. NSA can crack up 80bit encryption even today.


What if I told you that essentially, barring advancements in the
practicallity of QC, 128-bit keys will still be useful for your great
grand childrens secrets?

What if I would tell you that Enigma had lots of keypossibilities, so fact indeed that it should have been secure until 1970:s?


Using the "big number theorem" is the first sign of a person who just
doesn't get it. You're looking at it from a "what crypto can I throw
around" instead of a "what am I trying to accomplish" point of view.

No, you have missed my point. My point isnt just stacking up more bits, but to use robust algorithms and in cascaded mode to provide more security margin that just using "one 128bit cipherX" to secure information. It might be a bit slower on computer than using "one 128bit cipherX", but Im not saying this is something that should be used in every server, every connection, every message everywhere in the world. Its also nice to remember that secrets that are protected using good crypto can be very, very valuable.

--
My computer security & privacy related homepage
http://www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email
before sending it to me to protect our privacy.
.

Relevant Pages

  • Re: My little something...
    ... Its more unlikely that attack on 1024 ECC to subvert it to weaker than ... More secure ofcourse. ... Dont give BS about two cascading ciphers not neccessarely being more ... 10101 as hash. ...
    (sci.crypt)
  • Re: My little something...
    ... There is no reason to belive it is LESS secure. ... ciphers are cascaded and 1 of them fails, the second one still keeps the ... You are wrong to classify the threat (not the attack) as unknown, ... Does a break of AES imply a break of Twofish? ...
    (sci.crypt)
  • Re: what are best resources on cryptanalysis?
    ... A1) A Collision Attack On 7 Rounds of Rijndael ... A18) Breaking RSA May Be Easier Than Factoring ... A23) CA of Block Ciphers - The AES Case ... A56) DCA of DES-like Cryptosystems ...
    (sci.crypt)
  • Re: My little something...
    ... So where DES and FEAL, or even Knufu for that matter. ... been applied to a wide variety of ciphers from balanced feistels [DES, ... There is no reason to assume a future attack would apply only to AES. ...
    (sci.crypt)
  • Re: Needle in a haystack--or is this just stupid?
    ... > including the use of redundancy. ... than through brute force attack. ... I think that overstates the independence requirement. ... by adding redundancy in the form of sequential ciphers. ...
    (sci.crypt)