- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
// функция создания случайного ключа для шифровки/дешивровки сообщения
function keyCreate(): string;
const
alf: string = 'abcdefjhijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ0123456789';
var
i, k: integer;
logName: string;
begin
logName := '';
for i := 0 to 15 do
begin
k := RandomRange(1, 62);
logName := logName + alf[k];
end;
Result := logname;
end;
Follow us!
При условии, что RandomRange() - криптостойкий ГПСЧ, а не линейно-конгруэнтное говно из стандартной либы.
Если генерится человекочитабельный ключ - совершенно не напрягает. Просто его напрямую использовать нельзя.
> Херовый ГПСЧ тут не самое страшное, как ни крути.
У этого алгоритма чуть больше 2**95 вариантов на выхлопе, а у хренового гпсч - 2**32. Так что самое.
Собственно "шифровки/дешивровки" уже много чего говорит об авторе. Так что я таки ставлю на самописный алгоритм.
Чтобы записать его на бумажку и таскать с собой ;) Если энтропии в ключе или пароле хватает, какая в жопу разница, какими символами он записан? Ну захотелось человеку base-62, чтобы две закорючки в набор не включать.
> самописный алгоритм
Скорее всего, к сожалению.
Ещё вызывает недоумение название результирующей переменной. Може эта функция раньше генерировала названия для лог-файлов? :)
Но к нему можно применить какой-нибудь PBKDF, чтобы получить ключ, которым будет зашифрован ключ, которым будет зашифровано сообщение...
> И функция называется keyCreate.
Ну всё сходится, человек считает пароли ключами...
> лог-файлов
А зачем нужен лог файл со случайным именем? Обычно всё же дата какая-нибудь.
>Но к нему можно применить PBKDF, чтобы получить ключ, которым будет зашифрован ключ, которым будет зашифровано сообщение...
Я боюсь что автор не знает таких аббревиатур :)
А я боюсь, что поделие автора взломают через совсем другие дыры... Как и недавнего пациента, который считал 100500 хешей, а на ssh поставил пароль в духе васян888.
"Палатка с бронированной дверью", как писал Шнайер.
Вот так и увели.
А если серьёзно, то история очень похожа на историю чувака, который отправил говнокод для Андроида, спалив в исходниках свой пароль от яндексовской учётки. Если Вы понимаете, о чём я.
Что-то вспомнилось, вдруг.
>>> RandomRange
Дальше не читал.
http://arstechnica.com/security/2013/12/10/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/
Developers of the FreeBSD operating system will continue preventing users from trusting processors manufactured by Intel and Via Technologies as the sole source of random numbers needed to generate cryptographic keys that can't easily be cracked by government spies and other adversaries.
That decision, which will be effective in the upcoming FreeBSD version 10.0, comes three months after secret documents leaked by former National Security Agency (NSA) subcontractor Edward Snowden said the US spy agency was able to decode vast swaths of the Internet's encrypted traffic. Among other ways, The New York Times, Pro Publica, and The Guardian reported in September, the NSA and its British counterpart defeat encryption technologies by working with chipmakers to insert backdoors, or cryptographic weaknesses, in their products.
The revelations are playing a role in the decision for FreeBSD to continue restricting the use of hardware-based random number generators to seed the data used to ensure cryptographic systems can't be easily broken by adversaries. Specifically, "RDRAND" and "Padlock"—RNGs provided by Intel and Via respectively—will not be the sources FreeBSD uses to directly feed random numbers into the /dev/random engine used to generate random data in Unix-based operating systems. Instead—and has been the case for most of FreeBSD's history—it will be possible to use the pseudo random output of RDRAND and Padlock to seed /dev/random only after it has passed through a separate RNG algorithm known as "Yarrow." Yarrow, in turn, will add further entropy to the data to ensure intentional backdoors, or unpatched weaknesses, in the hardware generators can't be used by adversaries to predict their output.
In separate meeting minutes, developers specifically invoked Snowden's name when discussing the decision.
"Edward Snowdon [sic] -- v. high probability of backdoors in some (HW) RNGs," the notes read, referring to hardware RNGs. Then, alluding to the Dual EC_DRBG RNG forged by the National Institute of Standards and Technology and said to contain an NSA-engineered backdoor, the notes read: "Including elliptic curve generator included in NIST. rdrand in ivbridge not implemented by Intel... Cannot trust HW RNGs to provide good entropy directly. (rdrand implemented in microcode. Intel will add opcode to go directly to HW.) This means partial revert of some work on rdrand and padlock."
The meetings came shortly after a FreeBSD patch a third party submitted in July gave users the ability to use RDRAND and Padlock as direct sources of randomness. The update was committed without proper review and against established policy, and over the next few weeks all or parts of it were removed and recommitted FreeBSD Security Officer Dag-Erling Smorgrav told Ars. The change was finally removed altogether in October. Aside from the brief span earlier this year, no FreeBSD release has ever shipped with the option to feed the bit stream from a hardware pseudo-random number generator directly to /dev/random, Smorgrav said.
http://en.wikipedia.org/wiki/RdRand
* Посты проплачены AMD.
Такое правило в моей голове не позволяет мне читать посты, проплаченые amd
return time() & 1 ? 42 : null;
Я продвигаю путь php в массы.