pase@ogcvax.UUCP (07/10/86)
I am familiar with the internals of the RSA, but not the DES algorithm. The RSA scheme soaks up blocks of plaintext, then spits out blocks of cyphertext. Does the DES scheme do the same, or is it able to encrypt one character at a time? It seems that encrypting whole blocks would be most inconvenient for hardware whose sole purpose was to encrypt data for secure transmission across communication lines (say for a bank's automated teller machine). If one wanted to build add-on equipment that would attach, say, between a computer's RS232 port and a modem, which would encrypt data for secure transmission, would DES hardware be appropriate? Or would there be a delay while the box soaked up a block, encrypted it, then transmitted the result? I realize that a pipelined approach would be one alternative, but I would like to avoid the setup time required to fill the pipe. (It would be a three-stage pipe, soaking up a block, encrypting the block and transmitting it.) Thanks in advance for any/all replies
ark@alice.UUCP (07/14/86)
> I am familiar with the internals of the RSA, but not the DES algorithm. The > RSA scheme soaks up blocks of plaintext, then spits out blocks of cyphertext. > Does the DES scheme do the same, or is it able to encrypt one character at a > time? DES takes a 56 bits of key and 64 bits of plaintext and emits 64 bits of cyphertext.
phil@nike.UUCP (07/14/86)
> DES takes a 56 bits of key and 64 bits of plaintext and > emits 64 bits of cyphertext. Plain old DES (POD? Like Plain Old Telephone Service (POTS)?) does do this, using "electronic code book mode", or ECB. However, there are (proposed?) extentions to DES which permit stream ciphering. One such is Cipher Feedback Mode (CFB). To quote from the AMD data ciphering processor handbook, "Cipher Feedback operates on n-bit data blocks, 'n' being any value from 1 to 64. The content of the IV register is processed by the DES algorithm. The most significant n-bits of the result are exclusive-or'ed with the n-bit input data block. The result is the n-bit ciphered output block. This output block is shifted into the 'n' least significant bits of the IV register [hence the name 'chaining']." The book goes on to say that this works well for 8 bit data streams, but the resulting throughput is lower due to only using 8 of 64 available bits. I still have no relation to AMD, and the opinions expressed herein do not necessarily reflect those of NASA or the contractor to NASA for which I work. Phil
magik@chinet.UUCP (Ben Liberman) (07/15/86)
In article <1065@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes: > > ....... would there be a delay while the box soaked up a block, encrypted >it, then transmitted the result? > >I realize that a pipelined approach would be one alternative, but I would like >to avoid the setup time required to fill the pipe. If your available bandwidth can handle the traffic (if you can ship data faster than you are creating it) then you could constantly ship blocks padded out with random data. This eliminates input-to-transmission delays and may give greater security by not letting people know the frequency or size of your transmissions. ---------------------- Ben Liberman ihnp4!chinet!magik or ihnp4!homebru!magik
phoffman@well.UUCP (07/17/86)
>you could constantly ship blocks padded out with >random data. This eliminates input-to-transmission delays and may give greater >security by not letting people know the frequency or size of your transmissions. Is there a good way, then, of indicating where the random data ends and the real data begins? You wouldn't want to use the same sequence each time since it could be caught....
magik@chinet.UUCP (Ben Liberman) (07/19/86)
>>you could constantly ship blocks padded out with random data. >Is there a good way, then, of indicating where the random data ends and the >real data begins? One way would be to terminate the real data with a prearanged bit pattern flag (remember, all of this gets encoded before transmission) and then pad it out with random data. All of the block then gets encoded and the program on the other end, after deciphering the block, throws away everything in the block that follows the terminator flag.
michel@inuxa.UUCP (Alan Michel) (07/31/86)
How about taking parts of the key, and generate two initial seed values for long psedo-random sequence generators in a pre-determined way. Then use bits from one sequence to indicate when to place a random bit into the data stream and the other random sequence (or even later bits in the same sequence) to indicate whether that random bit should be a 0 or a 1. If you wanted to do more padding than doubling the size of the file, or you want to do less than doubling it, then you could take n bits at a time from the first random sequence. If the n bits happens to be a particular binary value(s), you pad in a bit from the second sequence. Otherwise, you pass a data bit straight through. For example, to pad the file to 9/8ths its original size (or there-abouts) take the first random sequence 3 bits at a time, and if it is equal to a predetermined value (say 010) then pad a random bit in from the second (or the same) stream into the data. If it is not 010, then put a bit in from the actual message data stream. On decryption, you generate the same pseudo-random sequence, throw out the bits that land in the positions marked by the sequence as being random noise, and keep the bits marked as the message by the sequence for further decryption or use. For extra security, the amount and method of padding actually done should be previously agreed upon and treated as part of the key. Also, this should be combined with other forms of encryption as needed. The method of generating seed values from the keys should be such that if the seeds were somehow figure out, they would not easily lead back to the complete keys, especially if the same keys have been used to encrypt the data in the first place. WARNING - I know next to nothing about real world cryptography. This seems like an obvious and quick way to pad data, but I do not know how easy it is to crack, or how much it may really increase/decrease security. Just a thought. Any comments?
sewilco@mecc.UUCP (Scot E. Wilcoxon) (08/02/86)
In article <189@inuxa.UUCP> michel@inuxa.UUCP (Alan Michel) writes: > > >How about taking parts of the key, and generate two initial seed values for >long psedo-random sequence generators in a pre-determined way. >Then use bits from one sequence to indicate >when to place a random bit into the data stream and >the other random sequence (or even later bits in the same sequence) >to indicate whether that random bit should be a 0 >or a 1. ...[example omitted] >WARNING - I know next to nothing about real world cryptography. >This seems like an obvious and quick way to pad data, but I do not know >how easy it is to crack, or how much it may really increase/decrease >security. Just a thought. I'm an amateur myself, having only designed and cracked a few dozen simple digital codes. His proposal sounds good for a distraction within or around a better code, but I can see two weaknesses: The first bits are less random than the rest are, and the more random (encrypted) the 'data stream' is, the better it will work. The first weakness is visible with ASCII English text as the input. Take the first bytes and try omitting the first bits to see if a printable character shows up. Then look at the next few bits to see what needs to be done to get the most likely English character. Keep that up and look for patterns in the identified encryption for clues to the keys (easier if the pseudorandom algorithm is known). The example in the original article used only 1 of 8 bits random, so good guesses will quickly be confirmed by real words showing up. Many more random bits are needed to obscure the data. When English text is encoded, the left-side weakness is obvious. But if the input data stream is pseudorandom (ie, encyphered data) then this blending of pseudorandom data is a bit more distracting. The question is whether or not analysis can identify the two different patterns, just as there are easy ways to identify the good guesses with English data. Perhaps analysis would show two different kinds of pseudorandomness which then could be separated. Or as someone recently pointed out perhaps sync characters or other artifacts of the data stream (I've easily broken several unknown algorithms on systems which used a certain line terminator or space padded data). Or there's always the possibility that a weakness in the key-to-sequence algorithm can be exploited to find either the key or part of the sequence. (Should we amateurs ramble in here?) While I have the podium, since my last "coding by location of typeset characters" article I've wanted to observe that this newsgroup is unusual as users of discussed methods tend to not identify themselves for obvious reasons. It's intriguing to know that ideas which generate no response may be idiotic or everyone who would comment won't because they've been using the method for years :-) -- Scot E. Wilcoxon Minn Ed Comp Corp {quest,dicome,meccts}!mecc!sewilco 45 03 N 93 08 W (612)481-3507 {{caip!meccts},ihnp4,philabs}!mecc!sewilco NASA:"Earth uninhabitable in 500 years." Welcome to tropical Minnesota.