waashk/20ng huggingface dataset:
In article <1qpg8fINN982@dns1.NMSU.Edu> amolitor@nmsu.edu (Andrew Molitor) writes: >Yes, those evil guys in the FBI can probably, with some >effort, abuse the system. I got news for you, if the evil guys in >the FBI decide they want to persecute you, they're gonna, and you're >gonna hate it. Fact is, the FBI doesn't want to listen to your phone >calls, and if they do, and if you're using triple-DES, they'll just >get a parabolic microphone and point it at your head.  Just because they can do it anyway, somehow, does not mean it is smart to make the job easier for them. -- "On the first day after Christmas my truelove served to me...  Leftover Turkey! On the second day after Christmas my truelove served to me...  Turkey Casserole     that she made from Leftover Turkey. [days 3-4 deleted] ...  Flaming Turkey Wings! ...    -- Pizza Hut commercial (and M*tlu/A*gic bait)
Quoting pla@sktb.demon.co.uk in article <8AOHOnj024n@sktb.demon.co.uk>: >You have every reason to be scared shitless.  Take a look at the records >of McCarthy, Hoover (J. Edgar, not the cleaner - though they both excelled at >sucking) and Nixon.
I'm attempting to write a serious policy paper examining whether the proposed wiretap (or "Clipper") chip is a cost-effective tool for police investigation.  That is, ignoring concerns about government intrusions into individual privacy, is the value of easy wiretaps to investigators greater than the cost to the communications industry, and their customers, to support this wiretap technology?    A rough estimate suggests that wiretaps are worth about five million dollars per year to U.S. law enforcement agencies.  (In 1990, 872 U.S. wiretaps led to 2057 arrests, while total police expenditures of $28 billion led to 11.25 million arrests [ref US Statistical Abstracts].) I'm working on estimating this wiretap benefit more accurately, but I'd like to ask hardware experts out there to help me with estimating the costs of the new proposed wiretap technology.  Please send me quotable/citeable estimates for:  - How many chips which would need to be made per year to keep all   phones with wiretap chips? - How much would it cost to make each chip? - How much did it cost to develop this technology in the first place? - How much more would supporting hardware, people, etc. cost, per chip? - What percentage cheaper would encryption chips and support have been   if private enterprise could compete to meet customer encryption needs? - What percentage of phone traffic would be taken up by the proposed   "law enforcement blocks"? - What is the total cost of handling all phone traffic per year?  Put another way, the question I'm asking is, what if each police agency that wanted a particular wiretap had to pay for it, being charged their share of the full social cost of forcing communication to be wiretap compatible?  Would they choose to buy such wiretaps, or would they find it more cost-effective to instead investigate crimes in other ways?
maa@plato.ds.boeing.com (Mark A Allyn) writes: >You all mention that the algorithm is classified and have expressed  >concerns and ideas of how to figure out the algorithm using software. > >The question that I have is why cant someone take one of these chips >and reverse engineer it? I mean, take the thing to a chip testing/ >analysis facility, one with a decent electron microscope. Just pry >off the top of the chip and start scanning it with the electron >microcope and figure out the circuitry. I remembered a place that I use >to work for had one of these facilities that they used to analyze chips >that we accidently blew out while running tests. They could actually find >the area that was fried and show us where in the circuit it was.  > >I am sure that many companies and universities must have these facilities >and that the potential is there, especially at a university where the >security at such a facility is looser, for someone to take a clipper >apart and analyze it? > >What can the government do to prevent this? Start taking away all  >microchip analysis facilities and electron microscopes??   They are using some technology developed by VLSI systems, the other manufacturer of the Clipper Chips, that produces chips that are supposed to be highly resistant to reverse engineering.  --
Richard Lucock (rmal@jet.uk) wrote: : I have seen various references to 'triple des' recently. Could anyone : tell me what it is ? From context, I would guess that it means : encrypting each block 3 times, with a different key each time, but : I'd like to be sure.  : Replies by email preferred - our news is unreliable.  Could people replying to the above question post their responses here as well, as I'm sure others (including myself) would like to hear them.  Thanks.  Jon
In article <EACHUS.93Apr20140314@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes: > >  But, if you are making custom equipment in any case, why not just >roll your own Clipper implementation and report the wrong keys to the >Escrow agency?  (Tells us who is going to be in the chip business if >this thing goes through--NSA, and those with something to hide from >NSA.)  This won't work if there is a checksum on the keys you don't know about. Neither will registering a clipper chip and then substituting a "counterfeit" one if the serial number contains a checksum.  Chances are the government has thought of this, and "just anyone" won't be permitted access to enough of the internals to make a "fake" clipper chip. Chances are that the government has classified some details of the internals at a very high level, and manufacturers are required to observe security safeguards and clearances corresponding to that level.  While not perfect, it would prevent Joe Hacker from rolling his own spoofing chip, since not many counterfeiters can survive a background investigation. Some of the more notorious self-styled dissidents here, for example, have already got their heads so high above the tall grass that they'd have little chance of getting a clearance.  Of course it's not impossible that someone do this, but probably extremely difficult. Chances are there will also be very heavy criminal penalties for phony clipper chips, on some national security/classified info grounds or other, thus making the game not worth the candle.
In article <1qhc2p$8d8@transfer.stratus.com>, cme@ellisun.sw.stratus.com (Carl Ellison) writes: > In article <1993Apr14.120229.15878@mnemosyne.cs.du.edu> rwebb@nyx.cs.du.edu (Russell Webb) writes: ... > Call me paranoid, but this is the same kind of scare story which Dorothy > Denning was citing while calling for the limitation of cryptography. >  > I doubt that DD is behind this --  >  > but I suspect that the FBI (and maybe NSA) are behind DD and those agencies > could easily be mounting a nationwide campaign (with our tax dollars?) to > build up public outcry against digital communication -- especially against > unbreakable, encrypted communication. >  >  > What's going on here?? >   Haven't you read any of Noam Chomsky's works? A widely used information net outside the control of the 'right people' is unthinkable. Hundreds of billions of dollars will be spent to wipe it out, sorry, 'regulate and order it' once the major media and poitical powers wake up to the efect it can have.  If you can't be bothered reading, get the video "Manufacturing Consent".
In article <1993Apr19.182327.3420@guvax.acc.georgetown.edu> denning@guvax.acc.georgetown.edu writes: 	[Prof. Denning's description of SkipJack mostly omitted]  	CHIP STRUCTURE 	The Clipper Chip contains a classified 64-bit block encryption 	algorithm called "Skipjack."  The algorithm uses 80 bit keys (compared 	with 56 for the DES) and has 32 rounds of scrambling (compared with 16 	for the DES).  It supports all 4 DES modes of operation.  Throughput is 	16 Mbits a second. [...]  	F, an 80-bit family key that is common to all chips 	N, a 30-bit serial number 	U, an 80-bit secret key that unlocks all messages encrypted 		 with the chip 	The key K and message stream M (i.e., digitized voice) are then 	fed into the Clipper Chip to produce two values:    	   E[M; K], the encrypted message stream, and  	   E[E[K; U] + N; F], a law enforcement block.    Three questions: 1) It looks like each 64 bits of input gives you 4*64 bits of output: 		E[M;K] = 64 bits 		E[K;U] = E[ 80 bits ] = 128 bits 		E[ E[K;U], N ; F ] = E[ 128 + 30 bits ] = 192 bits    Do you really need to transmit all 256 bits each time,    or do you only transmit the 192 bits of wiretap block at the beginning?       All 256 would be really obnoxious for bandwidth-limited applications    like cellular phones (or even regular phones over   2) how do the 4 DES modes interact with the two-part output?    Do the various feedback modes only apply to the message block,    or also to the wiretap block?  Or, if the wiretap block is only    transmitted at the beginning, does it get incorporated into    everything through feedback modes, but not during ECB mode?  3) Does the Clipper Chip check the wiretap block itself?    Does the block have to be present at all?    Since the receiving chip doesn't know the transmitter's U,    it presumably can't check the validity of E[K;U], so it's     limited to checking the *form* of the wiretap block,    and maybe checking the serial number for reasonableness    (unless there's some sort of back-door structure that lets    it recognize a valid E[K;U].)        In that case, can you replace the wiretap block with a DIFFERENT    wiretap block, presumably an old valid one to avoid attracting attention?    (The chip won't do it, so you postprocess the output.)    Regular people can do one with their own serial number and a dummy key;    paranoid people can use someone else's serial number.     On the other hand, if I could think of that solution so easily,    presumably the NSA could too - have they done something to block it,    like use message encryption that's really E[M; K,U,N] ?   	Thanks!
In article <1667.Apr1821.58.3593@silverton.berkeley.edu>, djb@silverton.berkeley.edu (D. J. Bernstein) writes: > Short summary of what Bellovin says Hellman says the NSA says: There is > a global key G, plus one key U_C for each chip C. The user can choose a > new session key K_P for each phone call P he makes. Chip C knows three > keys: G, its own U_C, and the user's K_P. The government as a whole > knows G and every U_C. Apparently a message M is encrypted as > E_G(E_{U_C}(K_P),C) , E_{K_P}(M). That's it. >  > The system as described here can't possibly work. What happens when > someone plugs the above ciphertext into a receiving chip? To get M > the receiving chip needs K_P; to get K_P the receiving chip needs U_C. > The only information it can work with is C. If U_C can be computed > from C then the system is cryptographically useless and the ``key > escrow'' is bullshit. Otherwise how is a message decrypted?
In article <1993Apr25.114820.14022@ulysses.att.com> smb@research.att.com (Steven Bellovin) writes:     In article <122723@netnews.upenn.edu>, feeley@cattell.psych.upenn.edu (Wm. Michael Feeley) writes:    > Just curious, how would the Clipper Chip system handle    > conference calls?     It's not Clipper, it's any encryption system.  I've seen a number of    designs; they generally involve a multi-line cleartext bridge.  Depending on the encryption system, so long as everyone has the same key, it can be done.  For example, I was using "vat", which is an Internet Audio tool, for a conference call, and we were encrypting the session.  (Unfortunately, one site was doing more work, and didn't have the CPU for it, so it didn't sound all that good at a different site)  So, you don't neccessarily have to have a clear-text bridge.  But if you do, its totally internal to one of the sites involved in the conversation....  -derek
And the fox has rabies too. --  Dave Feustel N9MYI <feustel@netcom.com>
In article <1993Mar31.014220.7701@Demax.COM> mikel@Demax.COM (Mikel Lechner) writes: > >You could just as well use a 16 character password to perform the encryption >of the 64 zero bits.  One simple method would be to use the first 8 characters >to encrypt the 64 zero bits and then use the remaining 8 characters to >encrypt the result again.  The output would still be 64 bits which encodes >into 11 ASCII characters. > Wouldn't this method be vulnerable against a "birthday" attack? Currently a cracker needs to find the _only_ (*1) key that produces the given ciphertext.  He has to try about 2^63 keys on the average. In the proposed method the cracker only needs _any pair_ of key halves. If he can store about 2^32 guesses for one half, he is likely to find a mathching pair in about 2^32 guesses.  (Here I have assumed that the DES-encryption is reversable, if the key is guessed.  Is this so or do the modifications of the S-boxes by the salt bits make it non-reversable?)
> I wonder if she landed such a fat fee from cooperation with the NSA in  >the design and propoganda stages that she doesn't care any more?
: At the company I worked for previously, I received a file that was des encryped : and the person that had sent it, went on vaction.  Rather than wait two weeks : I set up a straight frontal attack with one key at a time.  It only took two(2) : days to crack the file.  No, I don't have any faith in DES.  : A.G.  Fun!  Three questions:  1) What hardware did you use? 2) When you found the key, was there anything about it that was special    that meant you had been lucky to find it early? (Like the first 30 bits    all being 0) 3) ... or did you mean a dictionary attack rather than a binary key attack?
gtoal@gtoal.com (Graham Toal) writes:  >Can someone tell me if hardware compression is or is not needed to run >digital speech down 14.4K?  I think it is; I've heard it's not.  Lets >say 8 bit samples.  Would *raw* data at the corresponding sampling rate >be usable?  If not, how fancy does the compression need to be?  Note: I am *not* a cable freak, so I might have completely misunderstood what you said.  Also, my math is frequently noted for being wrong, so you'll better check the calculations yourself.  I assume that 14.4K means 14.4K Bits.  So if we assume one start and one stopbit, and no protocol overhead, the effective number of bytes per second is 1.44K.  Let's also assume that you do not want to transmit your speech in stereo, so that you can send 1,440 samples/sec.  This corresponds to a Nyquist frequency of 720 Hz, which should be too low, especially if you think about the 8-bit low quality sound.  Furthermore, your D/A converter will probably not present you with a signal that has been cut off at 720 Hz, but will instead alias in all the higher frequencies.  (Although you can definitely build a filter to overcome that problem.)  On the other hand, speech should be easily compressible.  For example, you could form power spectra, or you could simply band-pass filter and then linearize the fourier transforms.  It won't be CD quality sound, but it'll be discernible.  The power spectrum method is very good in that respect.  I have once programmed such a software compressor, and compression rates of 90% with relative errors due to linearization of less than 5% were common.  Although I must say that these were musical sounds, not speech.  Have fun.
>      But I think that mind-set is a mistake.   Before  there > were cattle prods, governments tortured their prisoners with > clubs  and  rubber  hoses.    Before  there  were lasers for > eavesdropping, governments used binoculars and  lip-readers. > Though  government certainly uses technology to oppress, the > evil lies not in the tools but in the wielder of the tools.  Evil and good walk hand in hand.  It is also important to note that the good in the tools lies in the wielder of the tools.  >      In fact, technology represents one of the most  promis- > ing  avenues  available  for  re-capturing our freedoms from > those who have stolen them.  I cannot accept this ridiculous leap in logic.  Technology is neutral to good or evil.  When technology is used by "evil" men, it is called evil technology.  When it is used by "good" men, it is called good technology.  Really, it is just technology that allows action to be realized more efficently and on a larger scale.  > By its very nature,  it  favors > the  bright  (who can put it to use) over the dull (who can- > not).  Try not to confused the development of technology with its use. Certainly, "bright" people will be better at creating technology, but even young children know how to program VCR machines.  Are VCR machines not extremely complex to create?  > It favors the adaptable (who are  quick  to  see  the > merit  of  the  new  (over  the sluggish (who cling to time- > tested ways).  Adaptibility and flexibility is always better at enduring than the stiff and stubborn.  A young child is soft and supple; an old man is stiff and inflexible.  A dripping of water can cut through stone. This has nothing to do with technology, rather technology just allows us to magnify action.  > And what two better words are  there  to  de- > scribe government bureaucracy than "dull" and "sluggish"?  I have no objection to this!  :)
brad@clarinet.com (Brad Templeton) writes: >And this means that the FBI will want to track the customer lists of >better encryption phones, because "the only reason a person would want >one is to evade the police."  	Then they'll probably also want to start tracking the customer lists of people purchasing SoundBlaster and similar boards, which can be configured with the use of some code and a modem, to act as a pretty decent digital-encrypting telephone. It's expensive, though, and kind of awkward. I don't know any drug lords, but I'm sure they'd favor something tappable over something secure as long as the user interface is nice.  	When you've got HRH Prince of Wales saying stupid things over cordless phones, it's not hard to imagine that drug dealers, child pornographers, commies, LISP programmers, and other threats to the civilized world might transact incriminating business over "encrypting" cellular phones.
However valuable, this discussion does NOT belong on comp.org.acm or on comp.org.ieee.  Please edit your followups to include only the appropriate newsgroups.
On the contrary, the entire Clipper proposal is an example of the government servicing the people (in the sense of the term found in the sentence, "The farmer paid $100 to rent a bull to service his cows.")
In article <rlglendeC5LrwC.95C@netcom.com>, rlglende@netcom.com (Robert Lewis Glendenning) writes: > I have been chided for stating that Dorthy Denning was intellectually > dishonest in the ACM debate and in this newsgroup.  I have previously > refrained from suggesting that she is arguing on behalf of consulting > clients. >  > Now, I say that it is clear that Dorthy Denning has been functioning > as a lobbyist, not a computer scientist.  She has used legal ethics > (truth is what you can convince anyone of), not scientific ethics > (truth is understanding the external world). >  > Maybe we can revoke her ACM membership? 8)
The recent discussion in this news group suggests that a key search attack   against DES is quite feasible now. But normally DES is applied in CBC or CFB   mode where one chooses a random init vector of 8 bytes. Questions:   - Makes it sense to handle the init vector as an additional key? Then we have   a 56 + 64 = 120 bit key.    - If yes: Is anything known about the security of this key scheme? Can we   break it faster than by exhaustive search through the 120 bit key space?
In article <C5wDFo.327@demon.co.uk>,  Graham Toal <gtoal@gtoal.com> writes: > In article <nagleC5w79E.7HL@netcom.com> nagle@netcom.com (John Nagle) writes: > :       Since the law requires that wiretaps be requested by the Executive > :Branch and approved by the Judicial Branch, it seems clear that one > :of the key registering bodies should be under the control of the > :Judicial Branch.  I suggest the Supreme Court, or, regionally, the > :Courts of Appeal.  More specifically, the offices of their Clerks. >  > I've got a better idea.  We give one set to the KGB c/o Washington embassy, > and the other set to the Red chinese. >  IMHO, one should place the keybanks into satellites (space). The  recovery should be done only by (highly visible) teams of astronauts.   --  Borut B. Lavrencic, D.Sc.     | X.400   :C=si;A=mail;P=ac;O=ijs;S=lavrencic J. Stefan Institute           | Internet:Borut.B.Lavrencic@ijs.si University of Ljubljana,      | Phone   :+ 386 1 159 199 SI-61111 Ljubljana, Slovenia  |	    PGP Public Key available on request
Vesselin Bontchev (bontchev@fbihh.informatik.uni-hamburg.de) writes:  >>Markowitz@DOCKMASTER.NCSC.MIL writes:  >>> It is interesting to note in this regard that permission to export >>> PKZIP's encryption scheme has twice been denied by NSA.  Draw you own >>> conclusions.  >>Uh, I'm afraid that your information is slightly out of date... PKWare >>has obtained a license to export their program to the whole world, >>except a very limited list of countries...  Draw your own conclusions >>about the strength of the algorithm...  :-)  Sorry if I was less than clear.  :-) I was referring to our own efforts to receive export permission from NSA for the PKZIP encryption algorithm, not to any effort on the part of Phil Katz or PKWare.  I should point out that the original version of this algorithm was designed by Roger Schlafly and that WE (meaning Roger and myself) were twice denied an export license for it.  The second go 'round was just this past fall.  I had no knowledge of Phil's attempts in this.  I do not even *know* for sure if he choose to implement the algorithm as it was designed by Roger, though I *believe* that was at least the case for versions prior to 2.0.  And then there's the question of key management.  :-)  And even if our applications were identical, there is no reason to assume the NSA would treat them that way.  :-)  -mjm
Thus said ee92jks@brunel.ac.uk (Jonathan K Saville): >D. Wigglesworth (smhanaes@gpu.utcc.utoronto.ca) wrote: > >: Do you know of any freely distributable c++ (or c) code for public >: key cryptography (such as RSA)?   > >: I've tried various archie searches to no avail.   > >Have you heard of PGP? I assume from your post that you have not. PGP 2.2 >is a freeware RSA encryption program which includes digital signatures and >comprehensive key management facilities. Most sites also keep the source code. >A growing number of people are using this excellent software to encrypt (to >a very high standard) their email and data. Get it before Clinton outlaws it. > >Two of the many sites are: >      rsa.com     /pub/pgp >      soda.berkeley.edu      /pub/cypherpunks/pgp  PGP is not available on the archive site rsa.com.  If it were, it would be highly amusing, since rsa.com (actually Public Key Partners, but it's the same entity) is the organization holding the patents which they claim are violated if you actually "make, use or sell" PGP. I believe those patents also apply in Canada, but I'm not a patent lawyer or anything.  There is no such thing as freely redistributable code for RSA which can be used in North America without legal entanglements.  You may wish to consider RSAREF, however, which *is* available from the FTP site rsa.com in /rsaref but probably doesn't meet your definition of "freely redistributable" (it's readily available in source, in C, and does RSA, MD5, etc. and comes with a license allowing noncommercial use.  Like any other strong crypto software, it's not exportable legally.  It can be modified with permission from RSADSI, which a number of people have received in the past.)  For reasons that aren't entirely clear to me, RSA says that only U.S. people should take RSAREF from its server, although there aren't ITAR issues regarding Canada.  The RIPEM distribution site (ripem.msu.edu) has RSAREF in its distribution, and is OK for Canadians. -- Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted