Re: is this double CBC?


"Joseph Ashwood" <ashwood@xxxxxxx> wrote in message
news:2NLAk.10708$Il.6977@xxxxxxxxxxxxxxx
Yes it does. Which would directly contradict your claim that an algorithm
doesn't.

i've never once said an algorithm does not work on 128 bits... i said an
implemented algorithm can NOT work on 128 SIMULTANEOUSLY!

Sunday Sept 14, 2008 2:26PM (Pacific Time) you spent a long paragraph
trying to explain how the AES algorithm used in CTR mode does not operate
on 128-bits, of course the it failed because the fact is that it does.
This appears to be the beginning of your claim.

no i didn't, so we will chalk that up to a communication break down and move
on.

And how does this address your claim that algorithms do not operate on
sizes different from implemenation?

again, i never made such a claim.

Here you're wrong again, the first architecture I am aware of to offer
128-bits natively was the Alpha AXP (later renamed just Alpha) since then
PowerPC has offered it since generation 5, the 64-bit SPARC processors
offer them as well, as does IA-64 (Itanium) and X64 offers them as well.
The only 64-bit architecture that didn't offer native 128-bit operations
that I recall is PA-RISC. But this doesn't change the fact that
implementations and algorithm can very often operate on different numbers
of bits.

that's harfdware my dear Joe, not software, 128 bits can be manipulated in
hardware in one operation, but in software it's not possible. "fact that
implementations and algorithm can very often operate on different numbers
of bits." my point exactly... a software implementation can, at best, with
64bit threading, can operate on 128 bits in two distict and seperate
software operations. while it is possible to operate on the full 128 bits if
the operation is multithreaded, to do so is a poain in the ass. and that's
being nice about it.

I understand what you are saying, paraphrasing your statements, I still
think the best is the claim that your process "Does not consume entropy,
but still uses random numbers" which is completely impossible. You also
keep denying that you claimed that implementations cannot operate
differently from algorithms. These seem to be the two big problems.

pseudo-random and random are like apples and oranges, the only similarity is
that they are numbers.

You have developed a (possibly) new way to waste computation time and
entropy. I say possibly, because there have been a lot of off proposals at
various times, there is always a possibility of a collision.

i can almost gaurantee that there is a collision in a very reasonable time
frame, because, as has been said many many times before, i'm not a
cryptographer. here is why i say that particular statement... implementing 4
8 4 byte counters, i can at maximum generate 2^128 individual states of
those 4 counters before they are all reset to 0. i use SHA512 as part of the
KDF, which has at most 2^512 variations before a collision occurs. in other
words, using 4 counters, after 2^128 permutations, everything is a
collision.

That is completely false. You have claimed that it is pseudo-randomly
generated, so I'll just go from the more strict rephrasing "if it is
pseudo-random then there is no entropy." Entropy is the measure of
unpredictability,

and if my module is completely predictable once a few primatives are known,
where is the entropy?

so you are claiming the CTR mode is pathetically weak. Every bit of
keystream in CTR mode is pseudo-randomly generated, if there is no entropy
there must be one and only one possible CTR keystream.

there is as many keystreams as the counter will allow for it's data type.

Actually you have repeatedly claimed both, you just haven't realized you
are. You claim there is no entropy consumed, that would be completely
unkeyed. Then you claim it is keyed, which directly violates the no
entropy claim.

no, i have never once said in this entire thread that i was not using a key.

ROT-13 is nothing of the sort. However, the fact remains that ROT-13 is a
cipher, and that it is horribly weak.

ROT-13 is a substitution, substituting "a" with "m" A xor B replaces
character A with the result of A xor B, it's still a stubstitution, the ONLY
difference is ROT-13 is unkeyed

That is true, however you'll also notice that there is still that function
that is called prior to AES. So all you have done is provide different
pseudocode showing exactly the same movement of AES to a different level
in the structure.

again, i would have to disagree with you... AES will take any string input,
it doesn't have to be plaintext, it can be ciphertext, or something in
between the two, it still functions exactly the same way and does exactly
the same thing.

You clearly have not used a recent compiler. At present even using a
modern virtual machine such as the most recent Java is only slower than
ASM by a few percent, certainly far less than your claim of "several
thousand times."

you code something in Java, then code something directly in ASM, and tell me
there is not a very significant difference in timing.

But it does consume entropy.

if something has no randomness at all it has no entropy.

"pseudo-entropy" doesn't exist. The closest to the concept of
"pseudo-entropy" would be entropy that does not achieve maximum density,
but using that still consumes entropy.

using a fixed set of intructions to generate 'entropy' is not generating
true entropy... true entropy is unpreditable in every way, it therefore has
no fixed set of instructions in order to be generated

Since you have not revealed enough to implement it, all I can be certain
of is that it violates all the requirements of the CBC proof. However, I
will point out that you have claimed that it is not a chaining mode, as
such it bears no resemblence to CBC.

taking a block of ciphertext, and combining it with a block of plaintext
before combining the result with the key is exactly CBC, you said it
yourself, and it is exactly what i appear to be doing, so unless there is
something new about CBC that i'm unaware of, how i reach the ciphertext
block is irrelevant.

The Debian OpenSSL bug completely destroyed the security, and didn't touch
the cryptographic algorithms, or the chaining mode. Draining the entropy
pool does "destroy the security." You are consuming entropy, therefore you
are weakening the system. So your statement is provably incorrect, in fact
that is most of what we have here, you claim it doesn't consume entropy,
and then you prove it does, you claim it isn't a chaining mode, then you
claim "it does look like CBC" these statements simply cannot both be true.

i claim it was not intended to be a chaining mode, but that is entirely
beside the point

you keep going on about draining entropy, how did we even get on to this? i
don't remember... it was a simple question about CBC, and you have gone
completely off on an entirely different tangent. i propose, we just agree to
disagree on this and get back to the original point of the thread.

can CBC or any other mode be applied to a block, as well as each element of
the array that make up the block, yes or no.


.

Relevant Pages

  • Re: real random
    ... Fortuna is, excluding everything they have to say on the matter. ... Are you literally saying that Fortuna is not an algorithm? ... have a source of entropy. ...
    (comp.lang.c)
  • Re: real random
    ... Feel free to post such an algorithm, ... it as a generator of a stream of numbers, ... You need a genuine source of entropy, ... By suggesting Fortuna (which gathers genuine entropy as it goes), ...
    (comp.lang.c)
  • Re: cipher program
    ... > Both the program code and the cipher are, well, atrocious. ... > Determining that 16 bits of entropy is all the passphrase does. ... >> might be achieved with a more complex algorithm, ... > It's periodic XOR with a fixed period of 2^16 bytes. ...
    (sci.crypt)
  • Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
    ... If the key expansion or shuffles are generated from an algorithm only ... Because the offsets is very far between eachother. ... actual algorithm is totally scaleable *AND NOW REAL CRYPTOGRAPHERS* ... shmeems and fleems about entropy may indeed be true in some other ...
    (sci.crypt)
  • Re: Encryption key length (RC4 and Blowfish)
    ... >there was an eavesdropping attacker, ... >with anyone breaking the cipher but solely whether you can distinguish ... >>CBC is a method, and has no entropy at all. ...
    (sci.crypt)