Re: My little something...

Markus Jansson wrote:
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.

Well until you have half a clue it's best to rearrange your thinking.

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.

So that's a reason to pair Twofish-256 with ECC-1024? Your logic, it
escapes me.

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.

There is no reason to assume that's true. We don't know how fast
unknown algorithms will work because they are unknown. Recall in the
70s breaking RSA would take millions of years. Then they invented the
QS.

If someone invents a QS like algorithm for ECC with a comparable
runtime for given bit lengths we're going to be screwed. We'd have to
use huge ECC curves for any sort of security.

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.

"more secure"? Can you break AES-256? Can you break Twofish-256? How
is using both "more secure" [or serpent or whatever].

And there is no reason to assume that the combo is more secure, and
besides, since you are double crypting there is a MITM attack. So it's
not a good idea.

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?

That's the point. You assume you know how the breaks will turn out
then you defend against them. However, you DON'T know how the breaks
will turn out so making non-standard protocols around attacks that
don't exist [yet] is foolish.

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

Actually no.

And you know this for a fact?

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.

Why is that the most logical way a break will occur. It's just as
equal probable that the two halves will be correlated.

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.

You're assuming they're totally uncorrelated.

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...

oh, ok you're not ignorant, you're just an ***. Ok. I don't see
how enigma plays into this. Using large salts doesn't increase
security provided you haven't used the same salt before. Salts are
PUBLIC KNOWLEDGE.

Different PRNG:s use different entropy sources and in different ways.

Really? ...

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.

I wanna buy your magical platform where you have many independent
totally random sources of entropy. Man oh man what a dream to work
with.

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...

Um first off, iirc it uses /dev/random for the entropy pool. That's
good enough in my books. Second, cascading ciphers is NOT a good idea,
that's why people don't do it.

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.

Really? Where is your proof of that statement?

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?

Um, except that the computers of the 70s could break most Enigma codes.


You're not making valid points because you don't know what the hell
you're talking about.

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.

The problem is "more secure" is not well defined. You assume AES will
be broken and that AES+Whatever is "more secure". You totally disregard
that "Whatever" may also be simultaneously broken rendering the
composition useless, worse yet you disregard that the specific
composition may prove insecure.

You just assume it's a good idea because you don't consider how things
interact.

More importantly you don't define what "less secure" is in any sort of
concrete terms. You assume all breaks will fall within your well
aligned parameters and that your defenses are the exact countermeasures
to the attacks which have not yet been developed.

I'd love to live in your world where you can just make up any random
fact, mention "NSA" somewhere and then think you're all smart and all.


Dude, quit the trolling, move out of your parents basement and get a
life.

Tom

.