From 22ce77bbdd5797a1984f10dd6361c550bff98566 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Sat, 26 Mar 2016 13:22:02 +0300 Subject: [PATCH] =?utf8?q?=D0=93=D0=9E=D0=A1=D0=A2=2034.13-2015=20=D0=BD?= =?utf8?q?=D0=B0=D0=BA=D0=BE=D0=BD=D0=B5=D1=86-=D1=82=D0=BE=20=D1=81=D1=82?= =?utf8?q?=D0=B0=D0=BD=D0=B4=D0=B0=D1=80=D1=82=D0=B8=D0=B7=D0=B8=D1=80?= =?utf8?q?=D1=83=D0=B5=D1=82=20=D0=B2=D1=8B=D1=80=D0=B0=D0=B1=D0=BE=D1=82?= =?utf8?q?=D0=BA=D1=83=20MAC?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit В старом стандарте шифрования ГОСТ 28147-89 был описан MAC, который просто стыдоба, хотя наверное простительно на тот момент создания, так как не было ещё атак и криптоанализов подобных функций. Проблема с MAC 28147-89: блоки дополняются просто нулями и поэтому можно получать идентичный MAC для сообщений отличающихся на некоторое количество нулей в конце. То есть нет никакого padding. В 34.13-2015 стандартизируют выработку MAC в виде CMAC. Лично у меня вообще нареканий к этому нет. Я бы сам сделал такой же выбор. -- 2.48.1