Cryptography-Digest Digest #862

2001-03-11 Thread Digestifier

Cryptography-Digest Digest #862, Volume #13  Sun, 11 Mar 01 14:13:01 EST

Contents:
  Re: Noninvertible encryption (John R Ramsden)
  Re: => FBI easily cracks encryption ...? (CR Lyttle)
  Re: Dumb inquiry (John Savard)
  Re: Dumb inquiry (Mok-Kong Shen)
  Re: => FBI easily cracks encryption ...? (SCOTT19U.ZIP_GUY)
  Potential of machine translation techniques? (Mok-Kong Shen)
  Re: boycott Russia ("Simon Johnson")
  Re: Dumb inquiry ("Simon Johnson")
  Re: boycott Russia ("Fedor V. Ignatov")
  Re: A question about passphrases (Kent Briggs)
  Re: A question about passphrases ("Scott Fluhrer")
  Re: I encourage people to boycott and ban all Russian goods and services, if the 
Russian Federation is banning Jehovah's Witnesses ... (stanislav shalunov)
  Re: OverWrite:  best wipe software? ("Tom St Denis")
  Re: Dumb inquiry ("Tom St Denis")
  Re: boycott Russia ("René")
  Re: boycott Russia ("Rene")
  RSA encryption on Windows -- C++ source code ([EMAIL PROTECTED])



From: [EMAIL PROTECTED] (John R Ramsden)
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Sun, 11 Mar 2001 16:17:57 GMT

Amethyste <[EMAIL PROTECTED]> wrote:
>
> a non invertible transformation has some drawback like this
>
> "do you mean"
>
> becoming after adding (randomly)  n e r i n g
>
> "done your meaning"
>
> and it is not the worse example I could find ...

It's true there are bad-case examples like this. But I suggest that
randomly added letters could be made far more obvious semantically
without compromising the overall randomness of the resulting text.

For a start it would generally be better to increase the length of
randomly added sequences, especially if these were embedded in words
to increase the average word length. (Remember, the distribution of
_spaces_ in the text may also help would-be decrypters.)

Making every randomly added sequence a separate word would greatly
simplify and "disambiguate" interpretation of the resulting text;
but it might introduce a chink in the armour from a cryptographic
standpoint, since spaces would always delimit random/non-random
boundaries. Also, it would probably be essential to embed random
strings in words in order to break-up commonly occurring letter
sequences within those words.

The program adding the extra random letters to words could include
checks that the result of padding a word would not be another valid
word, either as such or with any substring of the padding string
excised.

Also, before encrypting the padded text, the program could play
devil's advocate by running its own analysis on the text, for example
to ensure that the meaningful text had been diluted sufficiently for
the overall distribution of letter sequences to be adequately random.

> definitively a cryptosystem *must* be invertible

True. The only difference in this system is that the recipient is
required to complete the inversion, at a level of interpretation not
yet attainable by machines, the idea being to make the plaintext
syntax and, at a lower level (perhaps even more important), its
statistical characteristics much harder for those machines to
distinguish from a random string.

But I can see why the idea of an "open-ended" scheme like this may
worry and perhaps irritate mathematicians schooled in the formal
theory of algorithms ;-)

The key questions here are how much deviation from text "noise" is
required for a human recipient to be capable of picking out all the
signal, and is this threshold below what a machine, in the course
of a decryption attempt, would recognise as significant?


Cheers

===
John R Ramsden([EMAIL PROTECTED])
===
The new is in the old concealed, the old is in the new revealed.
   St Augustine.
===

--

From: CR Lyttle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 11 Mar 2001 16:36:20 GMT

Phil Zimmerman wrote:
> 
> What encryption was Hansen using that it was so easily cracked?

It was probably not anything very sophisticated, I would think. After
all Hansen was keeping his id secret from the Russians and they do not
seem to have been in regular electronic contact. If Hansen was using
anything as complex as PGP then he probably used only one key pair that
the FBI got from his home. Exchanging new keys for each transmission
requires two physical contacts, which increases the chances of being
detected. Most of th

Cryptography-Digest Digest #862

2000-10-07 Thread Digestifier

Cryptography-Digest Digest #862, Volume #12   Sat, 7 Oct 00 06:13:01 EDT

Contents:
  Re: what is wrapped PCBC? (Mack)
  Rijndael ([EMAIL PROTECTED])
  Re: Getting best available security without knowing which cipher to use (David 
Schwartz)
  Re: NSA quote on AES (Eric Smith)
  Re: Why wasn't MARS chosen as AES? (Eric Smith)
  Error-correcting code ? ([EMAIL PROTECTED])
  Re: Error-correcting code ? ("John A. Malley")
  Re: NSA quote on AES ("Brian Gladman")
  Re: NSA quote on AES ("Brian Gladman")
  Re: NSA quote on AES ("Brian Gladman")
  Re: NSA quote on AES (David Schwartz)
  Re: Looking Closely at Rijndael, the new AES ("Brian Gladman")
  Re: Q: does this sound secure? (Simon Johnson)
  Re: NSA quote on AES (Justin)
  Re: one time pad using a pseudo-random number generator (Mok-Kong Shen)



From: [EMAIL PROTECTED] (Mack)
Date: 07 Oct 2000 03:51:33 GMT
Subject: Re: what is wrapped PCBC?

>[EMAIL PROTECTED] (Mack) wrote in
><[EMAIL PROTECTED]>: 
>
>>>[EMAIL PROTECTED] (Mack) wrote in
>>><20001006000832.15659.0334@ng- fd1.aol.com>:
>>>
>>[snip]
>>>>
>>>>wrapped PCBC is basically a form of chaining similar to CBC and PCBC.
>>>>It uses multiple passes over the text wrapping the last block to the
>>>>front 
>>>>
>>>>It is a form of AONT.  If the encryption function is unbreakable
>>>>wrapped PCBC is unbreakable.
>>>>
>>>>example
>>>>
>>>>P1 P2 P3 P4
>>>>E1=f(P4^P1^P2)
>>>>E2=f(E1^P2^P3)
>>>>E3=f(E2^P3^P4)
>>>>E4=f(E3^P4^E1))
>>>
>>>  However in scott19u E1 does not overlay P1 there is a 9 bit shit 
>>>so that the file rotates 9 bits each pass.
>>
>>Interesting but it complicates the nice description.  I can see the use
>>but it slows it down.
>
>   Well scott16u is not slowed that much. Since I use
>an 8 bit shift. But scott19u. is dam slow with the 9 bit shift.
>I only ran it a few times on my 486. But scott19u flys on a k6-III
>that I know have.

I rather like AMD myself.

>
>>
>>>
>>>>
>>>>now here is where it gets interesting
>>>>
>>>>second round produces what we will call G
>>>>G1=f(E4^E1^E2)
>>>>G2=f(G1^E2^E3)
>>>>G3=f(G2^E3^E4)
>>>>G4=f(G3^E4^G1)
>>>>
>>>>notice that this is invertible
>>>>
>>>>In scott19u and relatives the second xor is changed to a +.
>>>>
>>>>It must be decrypted last block first to unwind it.
>>>>In particular scott19u uses large tables for f and round keys.
>>>>
>>>>This prevents 'the Onions attack' by Paul Onions which is
>>>>a form of Slide attack.  It is interesting that it isn't mentioned
>>>>in David Wagner's paper on Slide attacks.  I believe David may have
>>>>been around a bit when that attack was introduced.
>>>>
>>>
>>>  Well at the time David Wanger brought up his slide attack
>>>he made a grand statement that it was the death of my cipher
>>>until someone tried it and mentioned some of the problems  it
>>>caused for the slide attack. Wagner in only one small post 
>>>admitted that the slide attack may well not work against it
>>>but that he did not really understand what my code did.
>>>I guess having the complete source code that compiles was just
>>>to hard for him to follow.
>>> Actually I suspect he never looked at it at all and was just
>>>spouting BS out his mouth. Most people who attend Berkeley are
>>>quite arrogant. I konw I have met many of them and one of my siblings
>>>went there for 3 years. But then again there are a few rare
>>>good ones from there.
>>>
>>
>>Yes but you think he would have given Paul some credit.
>
>   Well I think the so called crypto gods only go around
>patting each other on the back. A ture independent thinker
>like Paul Onions is an embarassment to them. Its obvious
>he seems much sharper than Mr Wagner who has trouble reading
>code. I wonder how you followed my code when the so called
>experts could not. I don't see Mr Onions writting very ofen
>but I like his thoughts on various things.
>

I do coding work professionally.  Your code isn't the clearest
but it isn't the most opaque either.  It tends to be efficient
which generally leaves out clarity.  I generally write two versions
for code which will be publically available

Cryptography-Digest Digest #862

2000-05-26 Thread Digestifier

Cryptography-Digest Digest #862, Volume #11  Fri, 26 May 00 04:13:01 EDT

Contents:
  Re: Is OTP unbreakable? (Greg)
  Re: pentium timings and RC5 code (Greg)
  Q: appropriate number of key-uses before replacement? 
([EMAIL PROTECTED])
  Re: Is OTP unbreakable? ("Douglas A. Gwyn")
  Re: list of prime numbers ("Douglas A. Gwyn")
  Re: Help on factoring large numbers (100+ digits) (Scott Contini)
  Re: NTRU Anyone? (Scott Contini)
  Re: list of prime numbers (John Savard)
  Re: bamburismus (John Savard)
  Re: Schnorr patent and DSA (James Moore)
  Re: appropriate number of key-uses before replacement? ("Lyalc")
  Re: Another sci.crypt Cipher ([EMAIL PROTECTED])
  quantum computation (Koji Katakura)
  Re: Q: appropriate number of key-uses before replacement? (S. T. L.)
  interval arithmetic (was: Re: More on Pi and randomness) (Jonathan Thornburg)
  Re: Anti-Evidence Eliminator messages, have they reached a burn-out point? ("donoli")
  Re: Matrix key distribution? (Erich Schnoor)
  Re: Matrix key distribution? (Erich Schnoor)
  Re: Base Encryption: Revolutionary Cypher (wtshaw)
  Re: Retail distributors of DES chips? (David Hopwood)
  Re: Short Secure Serial Numbers (David Hopwood)
  Re: A Family of Algorithms, Base78Ct (Mok-Kong Shen)
  Re: quantum computation (Mok-Kong Shen)
  Re: bamburismus (Mok-Kong Shen)
  Re: NTRU Anyone? ("Antoine Joux")
  OAP-L3:  Version 5.x Revealed (Anthony Stephen Szopa)



From: Greg <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Thu, 25 May 2000 23:33:05 GMT


> ...is finite, the same number of possible keys."  Of
> course, "it is shown" refers to arguments later in his paper.

And of course you really don't need any math to state the obvious,
now do you?  The statement you quoted stands on its own merits.



--
There is only one gun law on the books- the second amendment.
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.


Sent via Deja.com http://www.deja.com/
Before you buy.

--

From: Greg <[EMAIL PROTECTED]>
Subject: Re: pentium timings and RC5 code
Date: Thu, 25 May 2000 23:41:05 GMT


> No they are saying it's possible to time it, just that my code
> sucks. Well Guys go ahead.

Well I disagree and as someone who has done this in the past I think
I know what I am talking about.  The Pent is extremely subject to
its environment and thus the environment prevents you from timing
anything ran on a Pent.  The only way to do it is to manufacture
a mother board that cranks the maximum through put of a Pent, then
write your own OS that will NEVER interrupt your code flow, and will
never allow a peripheral to access the bus and mess up the bus timings,
ect.  But then this is unrealistic.

You can write your code to run say 100 bytes per microsecond under
such an unrealistic OS.  Then run it in windows
and get it to run 80 bytes per microsecond.

You can then tune it to produce 90 bytes per second under the
unrealistic OS and 110 bytes under Windows.

So what have you gained by measuring anything in the first place?


--
There is only one gun law on the books- the second amendment.
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.


Sent via Deja.com http://www.deja.com/
Before you buy.

--

From: [EMAIL PROTECTED]
Subject: Q: appropriate number of key-uses before replacement?
Date: Fri, 26 May 2000 00:05:30 GMT

Hello all. The literature suggests rotating keys
regularly, but I have yet to see suggestions on
how often is often enough?

For a 160-bit MAC, with a 2048-bit RSA, how many
encryptions are too many? Changing keys often
means the keys are more susceptable to tampering
in-transit...

There must be a happy medium, but I don't know
where to start. :)

Suggestions? Followups to [EMAIL PROTECTED]
would be most convenient for me, though replies to
the group will work. :)

Thanks! :)


Sent via Deja.com http://www.deja.com/
Before you buy.

--

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Fri, 26 May 2000 00:24:52 GMT

Greg wrote:
> And of course you really don't need any math to state the obvious,
> now do you?

History has shown that "the obvious" is *especially* in need of
carefully reasoned proof.  Your informal "proof" of OTP security
is so sloppily phrased that similar "reasoning" could be applied
to some systems which definitely can be cracked; i.e., it is not
a valid proof.

--

From: &

Cryptography-Digest Digest #862

2000-01-07 Thread Digestifier

Cryptography-Digest Digest #862, Volume #10   Fri, 7 Jan 00 14:13:01 EST

Contents:
  Re: Wagner et Al. ("John E. Kuslich")
  Re: Truly random bistream (Scott Nelson)
  Large Numbers Beginner Question ("Alexander J. Fanti")
  Re: Large Numbers Beginner Question (John Savard)
  Re: frequency analysis with homophones (Mok-Kong Shen)
  Re: OLD RLE TO NEW BIJECTIVE RLE (Tim Tyler)
  Re: Please Comment: Modified Enigma (Mok-Kong Shen)
  Re: Large Numbers Beginner Question (Mok-Kong Shen)
  Re: Why the Cryptonomicon in Cryptonomicon? (John Savard)
  REDOC: First use: key dependent S-BOXES ("karl malbrain")
  Re: Identifier anonymization (Mike Rosing)
  Re: Large Numbers Beginner Question (Doug Stell)
  Re: Large Numbers Beginner Question (David A Molnar)
  Re: Blowfish ("karl malbrain")
  Re: Wagner et Al. (Guy Macon)



From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Fri, 07 Jan 2000 09:21:06 -0700

NT is known to be secure when power is off, all drives and memory are
removed and battery acid is poured on the motherboard. It's just that NT
is hard to use in this configuration. :-))

Sorry for the sarcasm but I think there is merit on both sides of this
arguement.

On the one hand, physical security and perhaps some hardware
modifications can drastically increase NT security.

On the other hand, in most settings, where draconian security measures
cannot be employed and computers must allow ordinary users debugging
rights, and access to disk etc. there are significant vulnerabilities
and they are not widely appreciated because most high level language
programmers do not unserstand how a computer works!!

Page locking means that the virtual memory system is prohibited from
swapping data in RAM to the swap file on disk.  The memory is still
available to a rogue program that knows how to gain conrol of the
processor from the operating system and have it's way with it.  It does
not help that memory is wiped soon after keys are used.  While the keys
are in use, they are just laying around in memory and exposed to an
attacker who  has gained access to your computer. The program author cn
employ obfucatory techniques but a determines hacker will always win in
that event.

Under NT, a process may be started in such a manner that the process
inherits the security attributes of the calling process or user.  This
means that if a program can be executed it can also be called by another
rogue process and executed.  Under the latter case, the calling process
has complete access to the memory space of the called process.  

This means that if an attacker somehow gains access to a computer, he
could install software that changes the name of PeekBoo (or any other
code) and replaces PeekBoo with a calling process that calls the now
re-named PeekBoo. When the ersats PeekBoo is started, the user sees
PeekBoo come up and apparently operate as normal.  However, PeekBoo is
now under the control of the attacker's code which (say) uses a special
key instead of the normal PeekBoo key without informing the user.  Or,
perhaps the PeekBoo program now just whistles Dixie!!

Whatever.

A couple of years ago, CRAK Software wrote a little program to read and
record the passphrase  used by PGP just as a demo to show that it could
be done inspite of the fact that PGP used a non standard method of
reading the passphrase edit box.  Apparently PGP's authors were aware
that the standard password edit box used under Windows is easy to read
by anyone who has the Winsite tool or Revelation tool etc.  They used
some special code to input the text from the edit box but this text is
easily read by hooking the WM_GETTEXT message to the special edit box. 
The passphrase also has to eventually lay itself down in memory where it
could also be read.

There is very little software can do to protect itself from anyone who
can gain access to your computer either by physical means or by the
network through BackOrfice and similar trojans.

Resistance is futile...at least as far as crypto software on the PC is
concerned.

JK  htp://www.crak.com



Guy Macon wrote:
> 
> In article , [EMAIL PROTECTED] (Joseph Ashwood) 
>wrote:
> >
> >I find your claim that the memory space is not accessable somewhat suspect.
> >I for one have used MS VC++'s attach to process option for debugging quite
> >often, and have for the most part not had it fail, even on programs for
> >which I did not have source access. This indicates to me that there are
> >debugger calls in the system which allow access in just exactly the way you
> >claim cannot be done.
> >Joseph
> 
> It would help a great deal if you would argue against what is actually
> being claimed.  Try "the memory space is not accessable UNDER NT UNLESS
> 

Cryptography-Digest Digest #862

1999-07-10 Thread Digestifier

Cryptography-Digest Digest #862, Volume #9   Sat, 10 Jul 99 13:13:03 EDT

Contents:
  Re: futurama (NFN NMI L.)
  Re: Why this simmetric algorithm is not good? (Jerry Coffin)
  Re: randomness of powerball, was something about one time pads ("Douglas A. Gwyn")
  Re: Electronically Exporting crypto source (legally) (Dave Hazelwood)
  RSA ("ASB")
  CIA' KRYPTOS is cracked N6 ("collomb")
  Re: encrypt using ASCII 33 to 126 only? (Rat Heart /ASM)
  Re: Uncrackable? ([EMAIL PROTECTED])
  Re: How strong would this algorithm be ? ([EMAIL PROTECTED])
  Re: Stream Cipher != PRNG ([EMAIL PROTECTED])
  Re: The Iraqi Block Cipher (Boris Kazak)
  Re: Can Anyone Help Me Crack A Simple Code? (Glenn Davis)
  Re: RSA (Glenn Davis)
  Re: RSA ("ASB")
  Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day ([EMAIL PROTECTED])
  Re: How strong would this algorithm be ? ("Daniel Urquhart")



From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: futurama
Date: 10 Jul 1999 07:20:29 GMT

Go to http://www.futuramaoutlet.com. There (one link away from the main page)
you will find a nice, lengthy summarization of how the alien alphabet has been
completely cracked, save for 3 letters that have not been observed yet. All
observed messages are also there, along with the decryptions. For the specific
message you are describing (it appears in the opening sequence on every show as
well, as a yellow sign), the actual words may be found after my .sig.

Moo-Cow-ID: 31  Moo-Cow-Message: title

-*---*---
S.T.L.  (NFN NMI L. also) -===> [EMAIL PROTECTED] <===- 2^6972593 - 1 IS PRIME!
Quotations: http://quote.cjb.net Main site: http://137.tsx.org F00FC7C8 MOO!
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!" e^(i*Pi)+1=0  Mail block
is gone, but will return if I'm bombed again. It was an easy fix. Address is
correct as-is. Giving the correct address is COURTEOUS; junk gets in anyway.
Join the Great Internet Mersenne Prime Search at http://entropia.com/ips/ My
.sig is even shorter, and contains 3046 bits of entropy including next line:
-*---*---

Card-holding member of the Dark Legion of Cantorians, People for the Ethical
Treatment of Digital Tierran Organisms, the Holy Order of the Catenary, the
Great SRian Conspiracy, the Triple-Sigma Club, the Polycarbonate Syndicate,
the Union of Quantum Mechanics, the Roll-Your-Own Crypto Alliance, and the
Organization for the Advocation of Two-Letter Acronyms (OATLA)
Avid watcher of "World's Most Terrifying Causality Violations", "When Kaons
Decay: World's Most Amazing CP Symmetry Breaking Caught On [Magnetic] Tape",
"World's Scariest Warp Accidents", "When Renormalization Fails", "World's
Most Energetic Cosmic Rays", and "When Tidal Forces Attack: Caught on Tape"
Patiently awaiting the launch of Gravity Probe B and the discovery of M39
Physics Commandment #15: Tidal Forces Fall Off As 1/r^3.



Some space...
10
9
8
7
6
5
4
3.1415926535897932384626433...
2
1

"Tasty Human Burgers"

Have fun!

--

From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Why this simmetric algorithm is not good?
Date: Sat, 10 Jul 1999 02:57:34 -0600

In article <7m62td$ors$[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...
> 
> 
> About the code I realize that I was wrong.  I would ask that people not
> talk about Micro-C as I do not speak on behalf of the owner.  Sorry for
> the mixup.  If anyone is wondering it is a good compiler.

Actually, it's an excellent compiler for what it is -- if I was doing 
embedded systems work, it'd be one of my first choices.  If you were 
writing your RC4 code with the idea of putting it on a smartcard or 
somesuch, compiling it with Micro-C would make a great deal of sense.  
OTOH, I suspect most people here write code primarily for either UNIX 
or Win32, and Micro-C doesn't do either one.

The closest it comes is DOS -- if you wanted to produce a really TINY 
version of RC4 for DOS, it'd be an excellent choice as well.  It can 
routinely produce complete programs of a few hundred bytes (compared 
to a couple of kilobytes for a null program from many mainstream DOS 
compilers).  In all honesty, shooting for tiny size probably makes as 
much sense as anything -- with the CPU of an average desktop machine 
the code would almost certainly be I/O bound regardless.

> Anyways this is OT, just to let you know (no bad thoughts about micro-c
> ok?)

It's less a question of good or bad thoughts that of your target -- if 
8-bit microcontrollers were your target, it might be worthwhile to 
code around any limitations it really has.  At the same time, Dave put 
a lot of work into the compiler and optimizer -- you might as well put 
that work to good use, and write 

Cryptography-Digest Digest #862

1999-01-07 Thread Digestifier

Cryptography-Digest Digest #862, Volume #8Thu, 7 Jan 99 21:13:03 EST

Contents:
  Re: U.S. Spying On Friend And Foe (Jim Dunnett)
  Re: On the Generation of Pseudo-OTP (Theo Honohan)
  Re: DES Hardware Implementation!! (Christof Paar)
  RSA source code? (Antonio ROMEO)
  Re: What is left to invent? (R. Knauer)
  Re: symmetric vs various asymmetric [was: DH is "stronger" than RSA?] (DJohn37050)
  Re: What is left to invent? (Helger Lipmaa)
  Re: What is left to invent? ("Nick Payne")
  Re: coNP=NP Made Easier? (rosi)
  Re: Help: a logical difficulty (Nicol So)
  Re: One-time pads not secure ? (NSA's Venona project) (Gideon Yuval)
  Re: On the Generation of Pseudo-OTP (Darren New)
  Re: On the Generation of Pseudo-OTP (Darren New)
  Re: Help: a logical difficulty (Nicol So)
  Re: coNP=NP Made Easier? (Matt Brubeck)



From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: U.S. Spying On Friend And Foe
Date: Thu, 07 Jan 1999 19:53:16 GMT
Reply-To: Jim Dunnett

On Wed, 6 Jan 1999 22:52:57 +, Withheld <[EMAIL PROTECTED]>
wrote:

>In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
>"Tony T. Warnock" wrote:
>> The great problem of "friends" spying on the US is that the
>> "friend" may not be able to keep secrets. Some of our allies may not
>> mean harm to us, but they cannot keep secrets. Vice versa.
>
>The British can keep secrets, and they have an Official Secrets Act to
>enforce it.

I fail to see how the OSA makes someone keep secrets!

There have been as many Brit defectors as American.

-- 
Regards, Jim.| A drunk man is more likely to find a
olympus%jimdee.prestel.co.uk | woman attractive. So if all else fails,
dynastic%cwcom.net   | get him drunk.
nordland%aol.com | - Dr Patrick McGhee, who coaches women
marula%zdnetmail.com |   on successful dating. 
Pgp key: wwwkeys.uk.pgp.net:11371

--

From: Theo Honohan <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: 07 Jan 1999 21:00:04 +

[EMAIL PROTECTED] (R. Knauer) writes:
> On Thu, 07 Jan 1999 17:37:37 GMT, Darren New <[EMAIL PROTECTED]>
> wrote:
> 
> >Heck, SGI (if I remember who properly)
> 
> Yes it is SGI, although I cannot find it anymore.

It's (still) at http://lavarand.sgi.com/.

--

From: [EMAIL PROTECTED] (Christof Paar)
Subject: Re: DES Hardware Implementation!!
Date: 7 Jan 1999 21:50:45 GMT

Samer EL HAJJ ([EMAIL PROTECTED]) wrote:
: Hello!
: I'm working on the hardware inmplementation (with VHDL into an FPGA)  of
: DES decryption.
: after many searh I did not find any publication or example about this
: topic.
: 
: Can anyone point me to some documentation on the subject?
: Thanks in advance!!
: 


Please check our SAC '98 paper and Jens Kaps' MS Thesis, both of which
can be found on our web page at:

http://ece.wpi.edu/Research/crypt 

We implemented DES on Xilinx FPGAs and achieved encryption rates 
betweeen about 100 Mbit/s and 400 Mbit/s, depending on the degree 
of pipeling and loop  unrollment.

Hope that's of help,

Christof


>>>  WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES) <<<
>>>   WPI, August 12 & 13, 1999 <<<
>>> check  http://ece.wpi.edu/Research/crypt/ches   <<<

***
 Christof Paar,  Assistant Professor
  Cryptography and Information Security (CRIS) Group
  ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon: (508) 831 5061email: [EMAIL PROTECTED]   
fax: (508) 831 5491www:   http://ee.wpi.edu/People/faculty/cxp.html
***

--

Date: Thu, 07 Jan 1999 22:34:59 +0100
From: Antonio ROMEO <[EMAIL PROTECTED]>
Subject: RSA source code?

I need  the RSA C source code.
Can anyone help me?
Thanks.


--
Antonio ROMEO

=
Swiss Federal Institute of Technology
Department of Electrical Engineering
Integrated Systems Center (C3I)

EPFL-DE-C3i ELB-Ecublens
CH-1015 Lausanne
tel. +41 21 693 69 79
fax   +41 21 693 46 63
email  [EMAIL PROTECTED]
http://c3iwww.epfl.ch/people_frame.html
==




--

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is left to invent?
Date: Thu, 07 Jan 1999 23:01:52 GMT
Reply-To: [EMAIL PROTECTED]

On Thu, 07 Jan 1999 19:00:43 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:

>I believe that there are indeed an almost infinite number of
>ingeneous ways to devise session keys that are ch