Cryptography-Digest Digest #895, Volume #13 Wed, 14 Mar 01 04:13:01 EST
Contents:
Re: Online Poker RNG ("Dan Kimberg")
Re: Authentication Protocol Strength (Benjamin Goldberg)
Re: OverWrite: best wipe software? (Anthony Stephen Szopa)
Re: Instruction based encryption ("Michael Brown")
Re: OverWrite: best wipe software? (Anthony Stephen Szopa)
Re: Instruction based encryption ("Michael Brown")
Re: Instruction based encryption ("Michael Brown")
Re: Instruction based encryption ("Michael Brown")
Re: Super strong crypto ("Bryan Olson")
Re: Cheap hardware to break RSA? ("Andor Bariska")
Re: Cryptanalysis of GOST? (Frank Gerlach)
Re: Super strong crypto ("Bryan Olson")
----------------------------------------------------------------------------
From: "Dan Kimberg" <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Online Poker RNG
Date: Wed, 14 Mar 2001 01:10:28 -0500
"Terry Ritter" <[EMAIL PROTECTED]> wrote:
> I assume this implies some sort of radioactive event detector as well.
> Do you have a web page reference for such a card? I have never seen
> one.
I just spent about 20 minutes looking for one, with no luck, so perhaps I
misremembered (although it was a really vivid memory, darn it). There are
various hardware devices out there, but none of the commercial ones I found
depend on ionizing radiation. At least none that turned up in my quick
search. There are a few kits/plans though (some on your site, obviously),
and lots of pointers to Aware Electronics. But I'm guessing you'd already
know if there was such a device on a PCI card.
Anyway, what I was getting at with that parenthetic comment was that there
are cheap ways to add hardware random number generation to a system
(especially if you already have a suitably equipped Intel chipset). Even if
you don't completely trust them, hashing them into your PRNG seed is
certainly a win over using just some bits off the system clock and
keystroke/mouse timing, especially if you're worried that the
keystroke/mouse timing could be an avenue of attack. I'd worry about a
transient bug (maybe in a poorly tested update) zeroing all the mouse
timings, for example. Anyway, I think in practice the method used by
Paradise Poker is extremely safe (given that they typically have over a
thousand users logged on). But I was surprised, given that they opted for
an entropy-gathering approach, at the sources of entropy they selected.
dan
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Authentication Protocol Strength
Date: Wed, 14 Mar 2001 06:42:42 GMT
[EMAIL PROTECTED] wrote:
>
> Hi. I've been working on developing an authentication and key
> exchange protocol between two users using public keys and a trusted
> server. I would really appreciate it if some readers look at this
> protocol and tell post your response to any of it's flaws, or anything
> about it in general.
>
> Definition of variables:
> Av = Client's private key
> Ac = Client's public key
> Tv = Trusted server's private key
> Tc = Trusted server's public key
>
> Outline of protocol:
> Step 1 - The client generates a key pair: Av, Ac.
> Step 2 - The client encrypts Ac with Tc and sends it to the server
> Step 3 - The server decrypts Ac and sends the client the digital
> signature of Ac
> Step 4 - The client verifies the signature using Tc
> Step 5 - The client prepares a message consisting of "OK" with a
> timestamp appended to the server if verified correctly, or "NO" with a
> timestamp appended if it was not verified. This message is encrypted
> with Tc and sent to the server.
[snip]
> Please post any responses to this protocol in the news or please email
> me.
> Thank you for your time.
How does the client get Tc? The protocol *seems* decent, but it depends
on the client trusting that Tc really is from the trusted server.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Tue, 13 Mar 2001 23:06:42 -0800
Tom St Denis wrote:
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Benjamin Goldberg wrote:
> > >
> > > You claim to have demonstrated a "procedure whereby the OverWrite
> > >
> > >
> > > ><snip>
> > >
> > >
> > > The difference between theory and practice is that in theory, theory and
> > > practice are identical, but in practice, they are not.
> >
> >
> > Let me ask you then, using OverWrite and my procedure of a dedicated
> > hard drive partition, etc., why will not the desired file be
> > thoroughly overwritten? Give us just one objection and we will
> > pursue it like a pack of dogs pursues the fox.
>
> Well I can say it's inconvenient to partition my drive to use your tools. I
> will lose all my data!
>
> Tom
You need a better system. You need at least two hard drives and
these should already have partitions on them. In this case, you
would only have to repartition one of your existing partitions.
You could save the data on this partition in one of your other
partitions so you wouldn't lose it.
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Wed, 14 Mar 2001 20:25:52 +1300
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:Ncpr6.26696$[EMAIL PROTECTED]...
>
> "Michael Brown" <[EMAIL PROTECTED]> wrote in message
> news:EBlr6.915$[EMAIL PROTECTED]...
<SNIP>
> > Each 128 bit key is made up of 16 "instructions", each of length 8 bits.
> The
> > instructions go from the most significant bit down to the least
> significant
> > bit. The first 3 bits of each instruction are the instruction, x, and
the
> > next 5 bits are the parameter n.
>
> This won't work. Algorithms defined by their keys are normally weak since
a
> subset of keys will define completely linear or differentially weak
ciphers.
Yep. Dead right. What I forgot to mention in my original post was that I was
doing this as an exercise to see if I'd got the hang of linear/differential
cryptanalysis. I failed :(
> > "Mash" key according to the following method:
> > Xor key with previous 128 bits of plaintext
> > Repeat 11 times: Key = Key XOR (Key ROR 11)
> > (ROR = rotate right)
> >
> > This key mashing is done every 128 bytes.
>
> Is the key mashing invertible?
Nope :( David Finch pointed this out very well. Big screw-up here.
> > <=== BEGIN NOTES ===>
> >
> > The 128 byte key mashing is just a number I pulled out of the air, so
> quite
> > possibly is not enough or too often.
>
> byte key? or bit key? Having the user make 128-bytes of entropy would be
a
> pain.
Badly worded statement (by me). I meant mashing the key every 128 bytes. I
am not so sadist that I make people generate that much entopy! (However,
assembly programming generally gives people the wrong view :)
> > The instruction table is quite possibly insecure, having both rotate
left
> > and rotate right.
>
> Note that rotate right = n-bit - rotate left
Correct. I was running out of ideas for the table at that point.
>
> Tom
>
>
---
Michael Brown
Physics is no fun if you disregard friction.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Tue, 13 Mar 2001 23:37:29 -0800
Benjamin Goldberg wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Benjamin Goldberg wrote:
> > >
> > > You claim to have demonstrated a "procedure whereby the OverWrite
> > > ><snip>
> >
> > Let me ask you then, using OverWrite and my procedure of a dedicated
> > hard drive partition, etc., why will not the desired file be
> > thoroughly overwritten? Give us just one objection and we will
> > pursue it like a pack of dogs pursues the fox.
>
> A dedicated hdd partition will still not help the case for when the hdd
> compresses sectors. Also, if my computer's cache keeps blocks in memory
> for a very long time (for longer than the one, single, pc which you are
> developing on), and has a very large cache (maybe even larger than the
> dedicated partition), then your methods won't work.
>
> Of course, since I don't trust your code not to be a trojan horse, and
> not to contain virii, I am not going to dl it. The cost of the risk is
> much much much higher than the cost of a phyisically destroyable floppy.
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
I think you have not read my procedure thoroughly or understood it
completely.
"A dedicated hdd partition will still not help the case for when
the hdd compresses sectors."
You have just made a blanket statement with no support for it other
than to say that it is so. Why won't my procedure and software work
with a compressed hard drive?
Again, you set some parameters then arrive at your conclusion but
fail to explain the chain of events or logic that allowed you to
arrive at your conclusion?
Don't you think that you are clutching at straws? You are creating
imaginary circumstances that are unlikely or inconsequential to the
OverWrite program and procedures as they now exist.
The user can set any sleep suspension from 2 - 120 seconds between
passes that include fflush, fclose, etc. Additionally, you can see,
hear, and feel the hard drives being accessed. In light of what
I've explained, what do you imagine is or is not going on here?
So, come on, now, tell us why it won't work if your "computer's
cache keeps blocks in memory for a very long time" and "and has a
very large cache (maybe even larger than the dedicated partition)."
Does what you say matter if the hard drives have been written to
and the file overwritten pass after pass?
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Wed, 14 Mar 2001 20:31:47 +1300
"Sundial Services" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The notion of data-driven scrambling is an interesting one, although it
> is debatable whether it would provide the security you anticipate. For
> example, a computer could test hypotheses against a particular message
> (notice that your 5-bit "length" allows for a maximum length of 32
> bytes), and look for the first break. From any one break, the cipher
> could probably be prized open rather like a stuck zipper. A chain is
> only as strong as its weakest link.
>
> Complexity can hide weakness...
>
> ... and even Wal-Mart is selling 500mHz computers these days.
>
>
It, like good ol' Bill, has got a Zipper problem :)
You are totally correct. If you know the preceding 32 bytes (256 bits) of
plaintext and the 128 bit key, you would be able to decrpyt it in both
directions. However, finding these 384 bits is not viable by brute force
(see other posts for the many problems).
As I stated in my other replies, this cipher was not designed totally for
security. Rather, I did this as an exercise in cryptanalysis (which failed
miserably, hence the post to here :).
---
Michael Brown
Physics is no fun if you disregard friction.
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Wed, 14 Mar 2001 20:31:52 +1300
"Matthew Skala" <[EMAIL PROTECTED]> wrote in message
news:98lr8n$jmi$[EMAIL PROTECTED]...
<SNIP>
> One problem with this scheme is that it will tend to be highly linear; no
> matter what the key is, each ciphertext bit will tend to be
> well-approximated by a linear combination of plaintext bits.
How do you tell this? I actually tried to avoid linearness through inclusion
of rotation and use of the ciphertext. Subtraction and addition are highly
(100%) linear though, so maybe should be replaced in the table.
> A second problem is that there are a lot of weak keys, and furthermore
> those weak keys are not alwasy easy to describe. There are a *lot* of
> fundamentally different 16-instruction "programs" that will result in
> little or no difference between the plaintext and ciphertext; recognizing
> some of them is tricky.
Weak keys are definately a problem. However, I think good design of the
instruction table (the one that I posted is plain shocking for weak keys)
detecting and avoiding weak keys should be relatively easy.
> I'd also be worried about the mashing getting stuck in some kind of
> pathological loop. For instance, if I'm understanding your scheme right,
> a key of all zeroes and a plaintext of all zeroes will not only lead to a
> ciphertext of all zeroes, but also produce a new key after mashing that's
> still all zeroes. Furthermore, it's very easy to generate all zeroes even
> with some other key when your plaintext is all zeroes. So if you have a
> plaintext file that has a long stretch of all zeroes, I think it's quite
> likely that your key would eventually get crunched into all zeroes. Then
> the rest of that long stretch of zeroes will result in zeroes in the
> ciphertext, and furthermore, whenever you start sending nonzero data, the
> enemy will know exactly what state your cipher is in at that point, and be
> able to decrypt the rest of your transmission as well.
Actually, it is worse. The key can (and will after a maximum of 1.5k of
data) get stuck to zero, regardless of the input data. This is a serious
problem that I really should have picked up upon. A few changes definately
need to be made to the key mashing ...
> Chosen- or known-plaintext attacks seem to be a problem as well; it seems
> like if the enemy knows a reasonably long stretch of plaintext and the
> corresponding ciphertext, then they're in a good position to guess or
> control the state of the cipher, and that gives them all the rest of the
> plaintext.
I would have thought that you would always need to know the 32 bytes before
the bit that you know to figure out the cipher state at the start. Then you
need to know another 32 bytes etc. Could you please explain a little here
(or just point me in the right direction?
Also, I did this partially as an exercise in cryptanalysis (which failed
miserably, hence the post to here :).
> --
> Matthew Skala
> [EMAIL PROTECTED] :CVECAT DELENDA EST
> http://www.islandnet.com/~mskala/
---
Michael Brown
Physics is no fun if you disregard friction.
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Wed, 14 Mar 2001 20:44:34 +1300
"David Finch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Your key mashing has a serious flaw. I expect your key to become 0 after
128
> xor's. You should see your plaintext in your ciphertext or your plaintext
xor'd
> with itself shifted 1 bit after the first 1.5k, depending on how whether
your
> instructions accept 0-31 or 1-32 for n. Either way it looks pretty bad.
>
> You lose one bit of information each time you rotate and xor something
with
> itself.
>
<SNIP EXAMPLE>
> You should always ensure that your "mashing" function is 1 to 1. You can
add
> constants, you can do an unsigned shift (not a rotation) and xor that with
it.
> You can permutate the bits in any way. You can multiply it by an odd
number. You
> can encrypt it (but not using itself as a key). But you shouldn't do
anything
> that can't always be undone, because it means you may lose bits, and the
key may
> even get stuck at a constant like 0.
Whoops. I really screwed up on this one! Thanks for the pointers. But isn't
shifting then XORing just as bad as rotating and XORing?
I think, when looking at the rest of the problems with this cipher, it's
DOA. The key mashing's stuffed, and apparently is highly susceptible to
linear and differential cryptanalysis. Oh, and it's got lots of weak keys
and a zipper problem. Apart from that, it's great!
Also, apparently the instruction based encrpytion idea's a loser as well.
As this cipher obviously isn't a good place to try to figure out linear
cryptanalysis, do you have any suggestions? All I can find with google is
the theory, which is quite hard to figure out without something to try it
out on!
Thanks for your response (to all the people who replied to my post).
---
Michael Brown
Physics is no fun if you disregard friction.
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Super strong crypto
Date: Wed, 14 Mar 2001 08:00:05 GMT
Douglas A. Gwyn wrote:
>Bryan Olson wrote:
>> Douglas A. Gwyn wrote:
>> > I am concerned with taking some
>> > standard symmetric encryption algorithm, which is not
>> > proven to be secure against all possible cryptanalysis,
>> > and enhancing the way it is used to provide more security,
>> > to the point that I can have *confidence* that not even
>> > the best feasible cryptanalysis is going to be able to
>> > break it (more likely than some acceptable threshold).
>> The operative step is the lowering the standard, not the
>> changing of the key.
>
>I can't even parse that [...]
You start with a system not proven to be secure against all
possible cryptanalysis and end up with one in which you can
have vaguely stated confidence. That doesn't require your
key-changing scheme. The scheme you end up with still
flunks the "proven secure" test, and if you start with a
modern cipher (Rijndael, Twofish, Sherpent, others) then we
can already have confidence. The lowering of the standard
is what achieved the result, not the changing of the key.
--Bryan
------------------------------
From: "Andor Bariska" <[EMAIL PROTECTED]>
Subject: Re: Cheap hardware to break RSA?
Date: Wed, 14 Mar 2001 09:49:24 +0100
Sven Gohlke <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
[EMAIL PROTECTED]
...
>Why don�t You use analog computer to do this job?
Do a search on TWINKLE.
Regards,
Andor
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis of GOST?
Date: Wed, 14 Mar 2001 09:52:34 +0100
Rebus Mauser wrote:
>
> Is anything known about practical attacks on the GOST algorithm? I found a
> related-key differential attack which cannot be practically extended to the
> full 32 round cipher and a chosen-key attack which recovers the _secret_
> s-boxes with 2^32 encryptions, however i think this attack is mainly useful
> against dedicated hardware implementations. Also you have to keep in mind
> that even if the s-boxes are known, the algorithm itself isn't broken yet. I
> conclude that GOST still can be seen as secure, please tell me if I'm
> wrong...
The big difficulty in assessing GOST is that the s-boxes are not fix.
This appears to be a strength on the first look, but from the design
process of DES we now know that random s-boxes are not providing the
best strength. NSA hardened the IBM-designed DES s-boxes considerably.
An interesting feature of GOST is that they could provide their
"second-tier" allies with an inferior key generator, which creates bad
s-boxes.
I guess that even Engima would still be an incredibly strong system, if
the rotor wiring were part of the key (at least for a small number of
messages per key).
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Super strong crypto
Date: Wed, 14 Mar 2001 08:53:25 GMT
Douglas A. Gwyn wrote:
>Bryan Olson wrote:
>> ... You have no proof of insecurity of the block cipher
>> you start with ...
>
>I didn't specify the basic block function!
In this strand you wrote:
| (so the data encryption will be something like Rijndael with
| small parameters). Under such circumstances, anything that can
| be done to get in the way of the enemy cryptanalysts is welcome.
>However,
>*any* cipher with finite key is in principle crackable
>with enough resources and CT;
Just like your scheme with the key changes.
>the only question is the
>minimum necessary resources for a specified success
>rate against that system using a given key size. I took
>that obvious fact as my *starting place*, and it is a
>pity that you are so hung up on it.
And so far you've produced a more awkward system still
sitting at that starting place.
>> ... and no proof of security for the scheme you
>> produce.
>
>There are reasons why I'm not presenting you with a nice
>package with a ribbon tied around it, but not because
>the general concept has no merit.
The reason is clear. You wrote that in developing the
needed science:
| Step one would be to develop a formal treatment of the propagation
| of information through Boolean functions.
Step one is not done, and there's nothing showing that it
would support your scheme were it done.
>Several
>other people have evidently understood what I was getting
>at, and why. Maybe if you proceeded for a while on the
>"benefit of the doubt" principle you might join them.
There seems to be one camp conjecturing about what things
might be secure, and another trying to precisely pin down
assumptions and goals and then determine what does and does
not follow. In the direction I've taken, I'm happy with the
company.
--Bryan
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
