This last level of the krypton challenges changed direction with a different type of cipher, a stream cipher.
--------------------------------------------------------------------------------
$cat README 
Hopefully by now its obvious that encryption using repeating keys
is a bad idea.  Frequency analysis can destroy repeating/fixed key
substitution crypto.

A feature of good crypto is random ciphertext.  A good cipher must
not reveal any clues about the plaintext.  Since natural language 
plaintext (in this case, English) contains patterns, it is left up
to the encryption key or the encryption algorithm to add the 
'randomness'.

Modern ciphers are similar to older plain substitution 
ciphers, but improve the 'random' nature of the key.

An example of an older cipher using a complex, random, large key
is a vigniere using a key of the same size of the plaintext.  For
example, imagine you and your confident have agreed on a key using
the book 'A Tale of Two Cities' as your key, in 256 byte blocks.

The cipher works as such:

Each plaintext message is broken into 256 byte blocks.  For each 
block of plaintext, a corresponding 256 byte block from the book
is used as the key, starting from the first chapter, and progressing.
No part of the book is ever re-used as key.  The use of a key of the 
same length as the plaintext, and only using it once is called a "One Time Pad".

Look in the krypton6/onetime  directory.  You will find a file called 'plain1', a 256 
byte block.  You will also see a file 'key1', the first 256 bytes of
'A Tale of Two Cities'.  The file 'cipher1' is the cipher text of 
plain1.  As you can see (and try) it is very difficult to break
the cipher without the key knowledge.

(NOTE - it is possible though.  Using plain language as a one time pad
key has a weakness.  As a secondary challenge, open README in that directory)

If the encryption is truly random letters, and only used once, then it
is impossible to break.  A truly random "One Time Pad" key cannot be
broken.  Consider intercepting a ciphertext message of 1000 bytes.  One
could brute force for the key, but due to the random key nature, you would
produce every single valid 1000 letter plaintext as well.  Who is to know
which is the real plaintext?!?

Choosing keys that are the same size as the plaintext is impractical.
Therefore, other methods must be used to obscure ciphertext against 
frequency analysis in a simple substitution cipher.  The
impracticality of an 'infinite' key means that the randomness, or
entropy, of the encryption is introduced via the method.

We have seen the method of 'substitution'.  Even in modern crypto,
substitution is a valid technique.  Another technique is 'transposition',
or swapping of bytes.

Modern ciphers break into two types; symmetric and asymmetric.

Symmetric ciphers come in two flavours: block and stream.

Until now, we have been playing with classical ciphers, approximating
'block' ciphers.  A block cipher is done in fixed size blocks (suprise!).
For example, in the previous paragraphs we discussed breaking text and keys
into 256 byte blocks, and working on those blocks.  Block ciphers use a
fixed key to perform substituion and transposition ciphers on each
block discretely.

Its time to employ a stream cipher.  A stream cipher attempts to create
an on-the-fly 'random' keystream to encrypt the incoming plaintext one
byte at a time.  Typically, the 'random' key byte is xor'd with the 
plaintext to produce the ciphertext.  If the random keystream can be
replicated at the recieving end, then a further xor will produce the
plaintext once again.

From this example forward, we will be working with bytes, not ASCII 
text, so a hex editor/dumper like hexdump is a necessity.  Now is the
right time to start to learn to use tools like cryptool.

In this example, the keyfile is in your directory, however it is 
not readable by you.  The binary 'encrypt6' is also available.
It will read the keyfile and encrypt any message you desire, using
the key AND a 'random' number.  You get to perform a 'known ciphertext'
attack by introducing plaintext of your choice.  The challenge here is 
not simple, but the 'random' number generator is weak.

As stated, it is now that we suggest you begin to use public tools, like cryptool,
to help in your analysis.  You will most likely need a hint to get going.
See 'HINT1' if you need a kicktstart.

If you have further difficulty, there is a hint in 'HINT2'.

The password for level 7 (krypton7) is encrypted with 'encrypt6'.

Good Luck!

--------------------------------------------------------------------------------
There were also two hints in files "HINT1" and "HINT2":
--------------------------------------------------------------------------------
$cat HINT1
The 'random' generator has a limited number of bits, and is periodic.
Entropy analysis and a good look at the bytes in a hex editor will help.

There is a pattern!

$cat HINT2
8 bit LFSR
--------------------------------------------------------------------------------
So there was an executable "encrypt6" that would run in the folder /krypton/krypton6 and look for a file "keyfile.dat" owned by krypton7 located there.
"encrypt6" would take a plaintext file as its first argument and an output file for the resulting ciphertext as its second argument.
I thought I would need to generate a large ciphertext, so naively created a ciphertext for the installed dictionary 
located at /usr/share/dict/words before realising this wouldn't be required, as frequency analysis of words wouldn't really be relevant here.
I also created a file of only symbols and numbers and ran it against the encryption executable to confirm what the ciphertext of those would be.
They rendered into ciphertext as null, telling me that symbols, punctuation, and numbers are ignored.
Also, lowercase letters were mapped to uppercase.

It was about this point I realized I was overthinking the problem.
I simply needed a common plaintext file with a single character!
When encrypted the repeating pattern of the stream cipher would show through, 
since the same character is being encrypted continually - any pattern should be easy to spot!
So I created a file with a million "A" characters.
--------------------------------------------------------------------------------
$for i in {1..1000000};do echo -ne "A" >>A-plain.txt;done
--------------------------------------------------------------------------------
Then encrypting this with the random stream cipher used by "encrypt6" gave me a ciphertext.
--------------------------------------------------------------------------------
/krypton/krypton6/$ ./encrypt ~/A-plain.txt ~/A-ciphertext.txt
--------------------------------------------------------------------------------

Viewing the ciphertext in a hex editor inside of vi revealed a pattern
--------------------------------------------------------------------------------
vi A-ciphertext.txt
:%!xxd
--------------------------------------------------------------------------------
I repeated the exercise to create the ciphertext once more. 
--------------------------------------------------------------------------------
/krypton/krypton6/  ./encrypt ~/A-plain.txt ~/A-ciphertext2.txt
diff -s ~/A-ciphertext.txt ~/A-ciphertext2.txt
Files /home/krypton6/A-cipher.txt and /home/krypton6/A-cipher2.txt are identical
--------------------------------------------------------------------------------
This would check if the random number sequence used for the stream encoding the plaintext was the same every time. 
It was, but it would have been a fundamental error to assume this without checking.

I noticed the ciphertext 'random' pattern repeated "EICTDGYIYZKTHNSIRFXYCPFUEOCKRN".
I used this to calculate the key shift against the ciphertext of the next level password, krypton7 "PNUKLYLWRQKGKBE".
This gave me a plaintext password, but putting this back into the "encrypt6" program gave me a slightly different ciphertext.
(This error was probably tiredness on my part)
There were 3 characters different between the password ciphertext and my password ciphertext.
I iteratively adjusted the plaintext password to ensure when it was encrypted it gave the same value as the krypton7 password ciphertext.
--------------------------------------------------------------------------------
krypton6@krypton:/krypton/krypton6$ ./encrypt6 ~/plain2 ~/cipher2
krypton6@krypton:/krypton/krypton6$ cat ~/cipher2 ;echo
PNUKLYLWRQKGKBE
krypton6@krypton:/krypton/krypton6$ diff -s ~/cipher2 krypton7 
Files /home/krypton6/cipher2 and krypton7 are identical
--------------------------------------------------------------------------------
I had found the last password and completed the Krypton challenge series!
--------------------------------------------------------------------------------
$ssh -p2222 krypton7@krypton.labs.overthewire.org
 _                     _              
| | ___ __ _   _ _ __ | |_ ___  _ __  
| |/ / '__| | | | '_ \| __/ _ \| '_ \ 
|   <| |  | |_| | |_) | || (_) | | | |
|_|\_\_|   \__, | .__/ \__\___/|_| |_|
           |___/|_|                   
a http://www.overthewire.org wargame.

krypton7@krypton.labs.overthewire.org's password: 
Welcome to Ubuntu 14.04 LTS (GNU/Linux 4.4.0-92-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

krypton7@krypton:~$ figlet $(whoami)
 _                     _             _____ 
| | ___ __ _   _ _ __ | |_ ___  _ __|___  |
| |/ / '__| | | | '_ \| __/ _ \| '_ \  / / 
|   <| |  | |_| | |_) | || (_) | | | |/ /  
|_|\_\_|   \__, | .__/ \__\___/|_| |_/_/   
           |___/|_|                        
krypton7@krypton:~$ 
--------------------------------------------------------------------------------