А именно - AES-256. Сразу скажу, что блочное симметричное шифрование (а не асимметричное) было выбрано ввиду того, что возникла задача поточного шифрования достаточно больших объемов информации (в настоящий момент - ~50 мегабайт на одну операцию шифрования) - для такого случая асимметричные методы считаются неоптимальными из-за большего времени операции криптования. Собственно, сама реализация такой операции никаких проблем не вызвала, т.к. целевая платформа - .Net/C#, в которой есть реализация Rijndael "из коробки". Меня смущают два нижеизложенных нюанса.

1. Как идеологически правильно по паролю получать ключ? Разумеется, я понимаю, что лучше всего в качестве ключа использовать рандомный бинарный блок требуемой длины, но в моем случае требование однозначно: входная точка - пароль пользователя. Я не раз видел реализации AES, в которых байтовое представление пароля просто дополнялось до нужной длины нулями - мне это представляется не особенно правильным подходом (хотя математически доказать неправильность такого подхода я не могу). Сейчас я в качестве ключа использую SHA-256 от пароля. Смущает то, что доказательства правильности такого подхода у меня тоже нет.

2. Поскольку в моем случае используется CBC-режим, то вместе с ключом шифрования задается еще и IV (вектор инициализации). Я так и не нашел однозначного ответа на вопрос, нужно ли хранить IV  в секрете - в разных источниках видел упоминания о том, что IV никакой ценности без ключа не представляет, и его можно хранить прямо вместе с закриптованными данными (но доказательств такого подхода я не видел). С другой стороны, IV используется для последовательного криптования сцепленных блоков, чтобы предотвратить словарную атаку, и, соответственно, является как бы вторым ключом к зашифрованным данным - так стоит ли выкладывать этот ключ для любого желающего?

Я для Вас Америку не открою, но хочу напомнить некоторую вещь, которая возможно наведет Вас на дальнейшие размышления. Вспомните, КАК(!) на самом деле реализовано шифрование в PGP / GnuPG. Вы правильно заметили, что симметричные алгоритмы гораздо превосходят ассиметричные по скорости (особенно хорошо это заметно на больших объемах данных).

Ну так вот - там вначале незашифрованный материал шифруется именно симметричным алгоритмом (с очень высокой скоростью), потом сеансовый ключ для симметричного алгоритма (а он ма-а-аленький) уже сам шифруется при помощи ассиметричного открытого ключа реципиента. То есть речь идет о комбинированном шифровании с применением симметричных и ассиметричных алгоритмов... Может Вам как-то реализовать подобную схему? Тем более, что она хорошо описана и де-факто является негласным стандартом.

Очень рискую ошибиться, но я бы здесь провел достаточно натянутую аналогию с ассиметричным шифрованием. Как мы знаем, открытый (публичный) ключ активно участвует в шифровании данных, однако публикация его безопасна.

P.S. А Вы пробовали похожие вопросы задать на pgpru.com - у его владельца Влада "SATtv'ы" Миллера (или у Unknown'a) - это самый компетентный ресурс по стойкому крипто на русскоязычном пространстве? ... Они ребята хорошие, вряд ли откажут.

1) PBKDF2 - должно быть прямо в библиотеках.

2) Вектор инициализации можно хранить публично вместе с зашифрованными данными. На практике его лучше всего вставить в поток данных перед данными, чтобы можно было начинать расшифровку потока до окончания его получения по сети. Тут имеет смысл только озаботиться защитой от его подмены или подмены фрагметов сообщения, например, передать в конце потока HMAC. В openpgp такая техника называетс mdc, можете посмотреть, как она там реализована.