Cryptography-Digest Digest #797, Volume #13 Sun, 4 Mar 01 17:13:01 EST
Contents:
Re: HPRNG ("r.e.s.")
Re: RSA Key Generation ("Mark Reed")
Re: HPRNG (Darren New)
Re: Super strong crypto ("Bryan Olson")
Re: Arcfour in Ada ("Julian Morrison")
Re: OverWrite freeware completely removes unwanted files fromharddrive (Steve Portly)
Re: OverWrite freeware completely removes unwanted files fromharddrive ("Tom St
Denis")
Re: HPRNG ("r.e.s.")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: Was there ever a CRM-114 Discriminator? ("Mxsmanic")
Re: OverWrite freeware completely removes unwanted files fromharddrive (Mok-Kong
Shen)
Re: The Foolish Dozen or so in This News Group ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Sun, 4 Mar 2001 12:21:22 -0800
"Darren New" <[EMAIL PROTECTED]> wrote ...
[...]
| Faith enters into science only to the extent
| that you assume the universe isn't trying to
| fool you and that the laws of physics aren't
| changing.
Curiously, the universe reveals through humans
a rather strong tendency towards self-deception.
It's a matter of faith that "scientific method"
is free of that tendency.
--r.e.s.
------------------------------
From: "Mark Reed" <[EMAIL PROTECTED]>
Subject: Re: RSA Key Generation
Date: Sun, 04 Mar 2001 20:45:37 GMT
"Paul Schlyter" <[EMAIL PROTECTED]> wrote in message
news:97npgg$o52$[EMAIL PROTECTED]...
> In article <2cGn6.56062$[EMAIL PROTECTED]>,
> Mark Reed <[EMAIL PROTECTED]> wrote:
>
> > In RSA key generation, 2 primes are found by getting random data and
setting
> > the most and least significant bits are set to ensure the prime length
is
> > half the required modulus length and that it is odd.
> > Then this is checked, then the next candidate (say by adding two) until
> > it is 'probably prime' enough for use.
> >
> > If only the top bit is set, the key length may be one less than
required -
> > as an example for a 512 bit RSA key with
> > p = 0x80......
> > q = 0x80......
> >
> > then
> >
> > n = 0x40......
> >
> > My question is whether this is common practice, or if generally the top
two
> > bits of each prime
> > (guaranteeing n > 0x90......)
>
> Guaranteeing n > 0xC0 !!!!!!
Guaranteeing p, q > 0xC0
Guaranteeing n = p * q > 0x90
>
> > I suppose another possibility is that primes are generated until n is
the
> > required bitlength.
> >
> > Unless this method is used, isn't security compromised ? ie. n can be
> > less than the number of bits required or the top two bits of each prime
> > are known to be one.
>
> The problem to be solved by this is that the modulus n must always be
> larger than the cleartext you want to encrypt. If the cleartext is larger
> than the modulus, then after decryption you won't get your cleartext
> back, but instead youll get cleartext mod n.
>
> One way to handle this is to, if you can detect whether the cleartext
> is correct or not, add back n to cleartext until you get the correct
> cleartext.
>
> Another way, and the most common way, is to make sure the modulus n
> always is larger than the cleartext.
>
> If your cleartest is ASCII data, or if it for some other reason the
> cleartedt always will have its highest bit clear, then ensuring that
> the modulus n always has its highest bit set is a way to ensure that
> the modulus always is larger than the cleartext.
>
> If your cleartext is binary data the situation gets more complex.
> One way is to format your binary data such that the highest bit always
> is zero. If you don't want to do this, all which remains is to generate
> RSA keys such that the X topmost bits of the modulus are one;
> then the probability of the binary cleartext being larger than the
> modulus is 2^(-X).
>
> By always setting the X topmost bits of your modulus to one, you
> will, form a security point of view, lose X bits of your RSA key
> size. Since X usually is a small number (1 or 2, sometimes perhaps
> somewhat larger) this is usually not a problem, but if you think this
> is a problem, it can easily be circumvented by increasing the size of
> the RSA key somewhat.
>
> --
> ----------------------------------------------------------------
> Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
> Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
> e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
> WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Sun, 04 Mar 2001 20:53:53 GMT
r.e.s. wrote:
> Curiously, the universe reveals through humans
> a rather strong tendency towards self-deception.
> It's a matter of faith that "scientific method"
> is free of that tendency.
Actually, I think most folks would say that science is a mechanism to try to
minimize this. The repeatability of experiments and testability of theories
is what separates science from charismatic assertion. While scientists may
deceive themselves, it is difficult for them to deceive other scientists.
If you think that science leads to more self-deception than (say) politics
or religion, you should probably back that up with some evidence.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Super strong crypto
Date: Sun, 04 Mar 2001 21:04:25 GMT
In Douglas A. Gwyn wrote:
>Bryan Olson wrote:
>> ... I don't see you will get any security results
>> based on just inventing new terms.
>
>I always edit out text not relevant to my reply,
>and I don't answer every question asked, for a
>variety of practical reasons.
And if you do not justify your claims or define what you
mean, I point that out.
> I'm sorry that you
> didn't understand the concept and choose to think
> of it as "just inventing new terms". When I say
> "threshold criterion" the meaning should be clear
> enough to anyone with training in statistics.
Nonsense. What you wrote was:
| My idea of "provably strong" allows for meeting a
| security threshold criterion, since for any practical
| system there always is such a threshold.
I am not asking you to define "threshold". I'm asking if
you can define your criterion in a way precise enough that
we can reason from it.
>When I talk about the "natural lifetime" of a key
>that is plain English that ought not to need
>explanation: if you use a key for too much traffic
>where the plaintext has exploitable statistical
>characteristics, then cryptanalysis is enabled,
>thus the earliest point before which such
>cryptanalysis is practical is the natural point at
>which to expire the key and replace it with a fresh
>one.
Did you make it up? Coining terms is fine, but you didn't
define it and you acted like I should know it already. In
particular, we do not know any "natural" point to change
keys for modern ciphers; for example there are no practical
attacks known for AES, or with recommended key sizes, RC4 or
RSA. (In the case of public key ciphers, changing keys does
nothing to restrict the availability of plaintext/ciphertext
pairs.)
> I don't have to tell you how the cryptanalysis
>would be done, which at any rate would depend on
>details of the system, but the *topic* as I
>interpreted it is what characteristics a practical
>cryptosystem might have that would foil any attempt
>at cryptanalysis no matter how clever the analyst.
You wrote that you thought the thread to be about provable
security, and you noted you had a criterion for such. Do I
understand correctly that you have given up on that, and are
now simply proposing systems you conjecture to be secure?
In particular, David Wagner asked why you chose to change
keys before the unicity distance. Your answer:
| This thread was apparently about provably strong encryption,
| which forces an information-theoretic approach.
Given what you've stated, this answer makes no sense. You
not have information theoretic security, and don't seem to
be taking that approach, or even seeking to demonstrate
security.
--Bryan
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.ada
Subject: Re: Arcfour in Ada
Date: Sun, 04 Mar 2001 21:08:09 +0000
"Thomas Boschloo" <[EMAIL PROTECTED]> wrote:
> But I figure that Arcfour has some overhead because of the extra keys
> you have to send :-)
You don't send extra keys, you send one partial key, you complete it with
a new IV each time it's used, and prepend the IV to the message.
> Funny that DoD doesn't have Rijndael in Ada, as they developed Ada in
> the first place :-P I had a large interest in Ada because the design
> philosophy appealed to me, but I figured it would be largely 'dead' by
> now and replaced by C++ and Java :-( I don't like C++, it's a mess.
There is Rijndael in Ada, available from the Adapower site. Unlikely to be
guv'mint code - bureaucrats are born with "security through obscurity"
hardwired into the soul.
> To Julian (if he still frequents this newsgroup, my reply is a bit
> overtime)
I do :-)
> , I figured you could just use one of those 16 bytes as a
> 'length' field. You would even keep 4 bits of that 'octet' for other
> purposes or future additions! The overhead doesn't seem as bad as you
> presented at first (I seem to remember somehow that you thought it was
> 64 bytes, I might be mistaken).
I can switch to Rijndael easily, since there's Ada code for it, but it's
fiddly and more bother than I care for, and the potential gain isn't great
enough to justify the hassle.
> And you wouldn't have the 'key' overhead in Arcfour (no idea how big
> that would be in the long run).
There isn't any, really, at least not any I wouln't need just as bad with
Rijndael.
> Here are some RFC's you might consider reading (if you hadn't done so
> already):
>
> RFC 793 (TCP), 1122 (fixes), 1323 (extensions) => TCP protocol RFC 768
> => UDP (very easy and simple to understand) RFC 791 => IP version 4 RFC
> 1883 => IP version 6 (longer addresses for the future)
>
> Protocols like TCP/UDP are layered on IP and the RFC's can tell you the
> sizes of the datagrams you can send with them.
Thanks for that info :-)
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Sun, 04 Mar 2001 16:18:32 -0500
Darren New wrote:
> Steve Portly wrote:
> > You presume that cache writing protocols are operating system specific.
> > The problem with cache clearing may be firmware related on some hard
> > drive configurations.
>
> That's true. However, I believe there are both SCSI and IDE specs for
> commands that flush even hardware buffers to the platters. These are used by
> (for example) Windows when it's shutting down.
>
> No, it's not a simple topic. :-)
>
> --
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> San Diego, CA, USA (PST). Cryptokeys on demand.
> Randomness: "To err is human"
> Pseudo-randomness: "That air is from beans."
If someone is in doubt about whether or not an overwrite command works on a
given platform it is relatively easy to verify. Just create a short C program
that overwrites a file using different characters. Put a printf just after the
cache flushing command in question. You can slow things down a little by adding
a 3 second delay between rounds. Now just run the program and listen for the
physical write between printf displays. Another test is to pull the power plug
as soon as you see the printf display that verified the physical write. When
you reboot look at the file contents to see if indeed the contents was
overwritten with the last character displayed.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Sun, 04 Mar 2001 21:23:11 GMT
"Steve Portly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Darren New wrote:
>
> > Steve Portly wrote:
> > > You presume that cache writing protocols are operating system
specific.
> > > The problem with cache clearing may be firmware related on some hard
> > > drive configurations.
> >
> > That's true. However, I believe there are both SCSI and IDE specs for
> > commands that flush even hardware buffers to the platters. These are
used by
> > (for example) Windows when it's shutting down.
> >
> > No, it's not a simple topic. :-)
> >
> > --
> > Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> > San Diego, CA, USA (PST). Cryptokeys on demand.
> > Randomness: "To err is human"
> > Pseudo-randomness: "That air is from beans."
>
> If someone is in doubt about whether or not an overwrite command works on
a
> given platform it is relatively easy to verify. Just create a short C
program
> that overwrites a file using different characters. Put a printf just
after the
> cache flushing command in question. You can slow things down a little by
adding
> a 3 second delay between rounds. Now just run the program and listen for
the
> physical write between printf displays. Another test is to pull the power
plug
> as soon as you see the printf display that verified the physical write.
When
> you reboot look at the file contents to see if indeed the contents was
> overwritten with the last character displayed.
>
>
Brute force solution? Ya sure I will just pull the plug violently on my
2,500$ computer... shaw right!
Tom
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Sun, 4 Mar 2001 13:28:22 -0800
"Darren New" <[EMAIL PROTECTED]> wrote ...
| r.e.s. wrote:
| > Curiously, the universe reveals through humans
| > a rather strong tendency towards self-deception.
| > It's a matter of faith that "scientific method"
| > is free of that tendency.
|
| Actually, I think most folks would say that science is a mechanism to try
to
| minimize this. The repeatability of experiments and testability of
theories
| is what separates science from charismatic assertion. While scientists may
| deceive themselves, it is difficult for them to deceive other scientists.
I agree with that, for the most part. At the same time,
it would be a mistake to consider the human enterprise
called "science" to be free of political and religious
agendas.
| If you think that science leads to more self-deception than (say) politics
| or religion, you should probably back that up with some evidence.
No, I don't think that, except in the above-mentioned
sense -- for which (I believe you'll agree) evidence
is more than abundant.
We're way OT for this forum, so I'll stop with this.
--r.e.s.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 04 Mar 2001 21:39:48 GMT
"kroesjnov" <[EMAIL PROTECTED]> wrote in message
news:97tbbn$2r1nt$[EMAIL PROTECTED]...
> I am willing to trade some privacy for safety.
I'm not.
> So what if they know that I don`t go to church?
You'll be first on the list when they purge the "heathens."
> So what it they know that I am a poor performer on school?
You'll be first on the list when they purge the "intellectually
inferior."
> So what if they know I am going to the hookers?
You'll be first on the list when they purge the "perverts."
> All the points above, and afcourse more off them,
> carry less weight for me then a terrorist bombing
> my school, or some luny invasing my country.
Unfortunately, all of them are also more likely than a terrorist bombing
your school or a nut invading your country.
> All things are relative in my opinion, and some things
> are just more important to me then others.
Apparently the things you don't have are more important to you than the
things you have. The grass is always greener on the other side of the
fence.
> How else are we going to catch someone like Saddam?
Catch him? Why?
> Yes, I really believe that.
Wow! A spook's dream come true!
> So call me young foolisch boy, who doesn`t understand
> these things, but my opinion stands.
We'll see what you call yourself twenty-five years from now.
> Afcourse they keep a mild track on everybody. To
> not do that, would be making it impossible to detect
> "the bad guy" among the good guys, you know that,
> and I know that.
There aren't any bad guys, until they do something bad.
> So, we have a goverment, who throws everybody in prison
> who has a gay friend?
Not always. Sometimes they might throw someone in prison for
_objecting_ to gay friends. It depends on which way the wind is
blowing.
> Yes indeed, the goverment is after us, better throw
> away your weed and porn, otherwise you are going to
> end up in a special rehab camp!
At the very least, if you are into weed and porn, be discreet.
> All of these things happend, because these agency`s
> were given to much power (wich is afcourse, the real
> discussion here).
_Somebody_ has to be given the power. But you have to audit and
distribute power.
> What is againts a world wide agency, that will
> keep track on bad people?
The main problem with it is that there is no objective definition of
"bad."
> So what if those agency`s aren`t perfect?
As long as they don't make their mistakes on you, I guess it doesn't
matter.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 04 Mar 2001 21:42:26 GMT
"Randoman" <[EMAIL PROTECTED]> wrote in message
news:hIwo6.7203$[EMAIL PROTECTED]...
> I don't want police & intelligence services reading
> my email or files. But I do want them to read the
> communications of people who might plant a bomb
> on the next plane I take.
But how can they know that you aren't such a person yourself, unless
they read your e-mail and files?
> Technology has advanced to the point where small,
> easily-carried items can kill a large number of
> people indiscriminately.
Technology advanced to that point long, long ago.
> I personally want some degree of protection against
> being possibly blown up or infected with some nasty
> genetically engineered, long-incubation-period,
> highly-contagious, high-fatality disease.
And once you have that protection, what will you do with it?
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: Was there ever a CRM-114 Discriminator?
Date: Sun, 04 Mar 2001 21:44:27 GMT
"John Savard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Since CRM-114 occurs in other movies by Stanley
> Kubrick, I think it is reasonable to suspect that
> it is something of personal significance to him ...
Do any of them predate _Dr. Strangelove_?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Sun, 04 Mar 2001 22:46:57 +0100
Steve Portly wrote:
>
> If someone is in doubt about whether or not an overwrite command works on a
> given platform it is relatively easy to verify. Just create a short C program
> that overwrites a file using different characters. Put a printf just after the
> cache flushing command in question. You can slow things down a little by adding
> a 3 second delay between rounds. Now just run the program and listen for the
> physical write between printf displays. Another test is to pull the power plug
> as soon as you see the printf display that verified the physical write. When
> you reboot look at the file contents to see if indeed the contents was
> overwritten with the last character displayed.
If I understood the discussions correctly, the point has
been that all the statements in a high-level programming
language cannot give absolute guarantee that the buffer of
the 'logical' file is actually flushed to the disk hardware
at any given time point, because the OS could keep a virtual
file for an indefinite time period in RAM (unless it is
forced to flush everything out to disk hardware at the time
it is shut down).
M. K. Shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 04 Mar 2001 21:58:52 GMT
Anthony Stephen Szopa wrote:
> So, what you are saying is that everything goes on in cache and that
> disk space is not under the operator's control. A file can be
> written to one place on a hard drive then read into cache.
> Processed then written to a completely different place on the hard
> drive. And this process can continue I suppose until the entire
> hard drive has been written over once and no bit locations have been
> overwritten.
> I would think this is not likely because of the optimization you
> claim to be expounding. The drive heads are already over these bit
> locations. To wander all over the hard drive writing to no
> predetermined fixed hard drive bit locations would be inefficient
> and un-optimizing.
Wrong. It is possible to ensure that the same disk blocks will
be ovrwritten (unless a new bad block gets added to the remapping
table during the process), but you have to open the file in a
particular mode (r+w in stdio terminology); if the file is opened
for writing in the default mode, it gets truncated to 0 length and
all its previous data blocks are returned to the block-buffer pool.
It is quite common for different disk blocks to get assigned as the
new file grows.
The more important point is that all the "overwriting" might take
place in the in-memory buffer pool, not on the hard disk itself.
UNIX systems usually have a daemon that flushes modified blocks
back to disk every 30 seconds or so, but obviously depending on
that for a process that overwrites disk blocks several times
would entail lengthy waits.
> Your hard drive was quiet because the heads did not move once they
> were in position. Is that about 1GB with no head movement in 156
> seconds? If you say so. This is not the point.
No, it was quiet because the updates all took place in the
in-memory buffer pool. That *is* the point.
> Like I said: What people fail to perceive quickly enough is that we
> are talking to several sick minds.
What *I* perceive is that you refuse to listen to good advice.
------------------------------
** 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
******************************
