Where do I get AES Key Schedule encryption key?

Question

I have implemented AES key schedule in Java but there is one thing I am confused about. In wikipedia (http://en.wikipedia.org/wiki/Rijndael_key_schedule#Key_schedule_description) it says:

The first n bytes of the expanded key are simply the encryption key.

Where does this "encryption key" come from? Is it generated randomly and if so what constraints you should generate it with etc?

At the moment I have a method that just generates a random array of 16 bytes:

public int[][] initvec() {
    int[][] key = new int[4][Nk];
    for (int i = 0; i < 4; i++) {
        for (int j = 0; j < Nk; j++) {
            key[i][j] = mrnd.nextInt(255) % (0xff + 1);
            int keyval = key[i][j];
            // System.out.printf("%x,",keyval);
        }
        // System.out.println("");
    }
    return key;
}

I would also like to print this key out however as java only has signed bytes if I use a number larger than 127 (currently 255) I will get negative numbers which can't be represented in a string properly using something like this where outputbyte is byte[] and has the integers converted into bytes and stored inside it:

String output = new String(outputbyte, StandardCharsets.UTF_8);

Is using 127 instead acceptable?

Answer 1

Where does this "encryption key" come from?

It's the key that the user supplies when something needs to be encrypted.

Is it generated randomly and if so what constraints you should generate it with etc?

It may be generated randomly. Then the challenge is to make known to the other side. One could for example then send the key encrypted through public-key crypto. This is called hybrid encryption.

Often a key exchange protocol such as Diffie-Hellman is used to negotiate the secret without it being sent fully assembled over the wire. This achieves forward secrecy, because every party will calculate the secret key on their own.

Is using 127 instead acceptable?

No, it isn't, because you're doing the whole thing wrong. Bytes 0x00 through 0x1F are not printable characters. So when you try to print those bytes even with a reduced byte domain of up to 127, you won't see the actual key. Also, by restricting the domain, you also help attackers, because now they don't need to brute-force the complete domain for every byte of the key.

You need to utilize the full capacity of the key byte when generating a random key. When you then want to see the key, you can encode it with Base 64 or Hex.