Прр расшифровка: Что такое ПРР на складе или в логистике?

Содержание

Аббревиатуры в логистике/Viconte Marine

Аббревиатура	Расшифровка	Значение
ATA	Actual Time of Arrival	Фактическое время прибытия транспортного средства
ATD	Actual Time of Departure	Фактическое время отплытия (вылета, выезда)
AWB	Air Waybill	Авианакладная, сопровождающая груз. Может быть двух видов: HAWB (House Air Waybill) – домашняя накладная, первоначально не имеет номера, но затем получает его от выпустившего грузового агента. Носит вспомогательный характер. MAWB (Master Air Waybill) – мастер-авианакладная, имеет номер, присвоенный авиакомпанией.
BAF	Bunker Adjustment Factor	Дополнительный топливный сбор. Взимается как часть от суммы фрахта или как фиксированная сумма за 1 TEU.
B/L	Bill of Lading	Коносамент, документ, сопровождающий товар. Используется при морских перевозках и мультимодальных перевозках с использованием морского транспорта.
CAF	Currency Adjustment Factor	Дополнительный сбор, взимается как надбавка или часть от суммы фрахта, зависит от колебаний курса валют.
CFS	Container Freight Station	Контейнерный пункт
CMR	Convention relative au Contrat de transport international de merchandises par route	Международная товаротранспортная накладная для автомобильных перевозок
CNEE	Consignee	Грузополучатель
CNOR	Consignor	Грузоотправитель
C/O	Certificate of Origin	Сертификат происхождения. Используется для определения страны происхождения (производства) товара.
COC	Сarrier’s Оwned Container	Контейнер в собственности перевозчика. Стоимость его использования включена во фрахт.
CSC	Carrier security charge	Плата за обеспечение безопасности перевозчика.
C.S.C	Container Service Charge	Плата за передачу поставок от причала перевозчику и наоборот.
CY	Container Yard	Контейнерный терминал
DIM	Dimensions	Размеры груза
DGR	Dangerous Goods Regulations	Правила перевозки опасных грузов
DOC	Documentation fee	Плата за оформление документов
DTHC	Destination terminal handling charges	Погрузо-разгрузочные работы в порту назначения
ETA	Estimated Time of Arrival	Ожидаемое время прибытия товара на место назначения
ETD	Estimated Time of Departure	Ожидаемое время отправления товара
EX-1	Export declaration	Экспортная декларация. Документ, предоставляющий все сведения об экспортируемых товарах.
FCL	Full Container Load	Полная загрузка контейнера
FEU	Forty foot equivalent Unit	40-футовый контейнер
FIATA	Federation International des Associations de Transitaires et Assimiles	Международная ассоциация экспедиторов
FI/FO	Free in/Free out	Без погрузки/выгрузки товара в порту
FIO	Free in and out	Судно не платит за погрузку и выгрузку.
FIOS	Free in and out and stowed	Судно не платит за погрузку, выгрузку и укладку товара на борту.
FT	Flat Rack	Контейнер-платформа с торцевыми стенками
HBL	House B/L	Коносамент, выданный экспедитором (домашний)
HQ	High Cube	40-футовый контейнер High Cube. Обладает большей вместимостью по сравнению с обычным контейнером.
IATA	International Air Transport Association	Международная ассоциация воздушного транспорта
IG	In Gauge	При доставке груза при помощи спецтехники – размеры груза не превышают размеров платформы.
INV	Commercial Invoice	Инвойсный счет – выписывается продавцом, используется для указания ценности товара.
L/C	Letter of Credit	Аккредитив. Подписывается в момент заключения контракта. Определяет условия платежа и сроки доставки товара.
LCL	Less than Container Load	Консолидированная перевозка – несколько грузов объединяются в одном контейнере.
LI/LO	Liner in/out	Погрузка и выгрузка товара за счет линии
LO/LO	Lift on/Lift off	Груз поднимается и опускается
LT	Local Time	Местное время
MBL	Master B/L	Основной коносамент. Выдается морской линией.
MV	Mother Vessel	Крупнотоннажное линейное судно
N/N	Nоn-negotiable Document	Документ, который не дает права на получение товара.
NVOCC	Non Vessel Operating Common Carrier	Брокер, продающий место под загрузку на судах, которыми он не владеет.
OBL	Original B/L	Оригинал коносамента
OOG	Out of Gauge	При доставке груза при помощи спецтехники – размеры груза превышают размеры платформы.
OT	Open Top	Контейнер без жесткой крыши
OTHC	Original terminal handling charges	Погрузо-разгрузочные работы в порту отправки
ORC	Origin receiving charges	Сборы в Китае
PACK	Packing List	Упаковочный лист. Дает представление о месте нахождения товара в грузе.
PCS	Port Congestion Surcharge	Сборы, зависящие от загруженности контейнерного терминала.
POD	Port of Destination	Порт назначения
POL	Port of Loading	Порт отправления
PSS	Pick Season Surcharge	Надбавка к фрахту, зависящая от сезонных колебаний спроса на перевозки.
RO/RO	Roll-on/Roll-off	Судно, принимающее на борт накатные грузы.
SWB	Sea Way Bill	Морская накладная
TEU	Twenty foot Equivalent Unit	20-футовый контейнер
THC	Terminal Handling Charge	Портовый сбор за передачу контейнера от причала перевозчику и наоборот.
TLC	Three-Letter-Code	Трехзначный код аэропорта
T/S	Transshipment	Перегрузка судна
T/T	Transit Time	Транзитное время перевозки
T-1	Transit declaration	Транзитная таможенная декларация
ULD	Unit Load Device	Контейнеры, паллеты, модули для погрузки багажа на борт самолета.
WHS	War Risk Surcharge	Надбавка к фрахту. Учитывает риск гибели судна и потери груза от военных действий.

Авиационные сокращения

А/А	Air to Air	Воздух — Воздух
AAF	Army Air Field	Военный аэродром
AAL	Above Aerodrome Level	Над уровнем аэродрома
AAS	Airport Advisory Service	Консультативное обслуживание в аэропорту
АВ	Air Base	Авиабаза
ABM	Abeam	На траверзе
ABN	Aerodrome Beacon	Аэродромный маяк
AC	Air Carrier	Авиаперевозчик, авиакомпания
АСА	Arctic Control Area	Арктический диспетчерский район
ACAS	Airborne Collision Avoidance System = TCAS	Бортовая система предотвращения столкновений
ACARS	Airbone Communications Addressing and Reporting System	Бортовая система связи с адресацией и сообщением
ACC	Area Control Center	Районный диспетчерский центр
ACFT	Aircraft	Воздушное судно
ACH	АТС Flight Pian Change Message (IFPS)	Сообщение об изменении плана полета (IFPS)
ACN	Aircraft Classification Number	Классификационное число воздушного судна
AD	Aerodrome	Аэродром
ADA	Advisory Area	Консультативный район
ADCS	Advance Customs	Предварительное уведомление о необходимости таможенного обслуживания
ADEP	Aerodrome of Departure	Аэродром вылета
ADES	Aerodrome of Destination	Аэродром назначения
ADF	Automatic Direction Finding	Автоматический радиокомпас
ADIZ	Air Defense Identification Zone	Зона опознавания ПВО
ADR	Advisory Route	Консультативный маршрут
ADS	Automatic Dependent Surveillance	Автоматическое зависимое наблюдение
ADV	Advisory Area	Консультативный район
AEIS	Aeronautical Enroute Information Service	Обслуживание аэронавигационной информацией на маршруте
AER	Approach End Runway	Конец ВПП со стороны подхода
AERADIO	Air Radio	Радиостанция (обслуживающая полеты)
AERO	Aerodrome	Аэродром
AES	Aerodrome Emergency Services	Аэродромная аварийная служба
AF Aux	Air Force Auxiliary Field	Вспомогательный аэродром ВВС
AFB	Air Force Base	База ВВС
AFIL	Flight Plan Filed in the Air	Зафайленый(Переданный) с борта план полета
AFIS	Aerodrome Flight information Service	Аэродромная служба полетной информации
AFN	American Forces Network	Сеть американских ВВС
AFP	АТС Flight Plan Proposal Message (IFPS)	Сообщение о предлагаемом плане полета (IFPS)
AFRS	Armed Forces Radio Stations	Радиостанции ВВС
AFS	Air Force Station	Станция ВВС
AFS	Aeronautical fixed service	Авиационная фиксированная служба
AFSS	Automated Flight Service Station	Автоматическая станция полетного обслуживания
A/G	Air-to-Ground	«Воздух—Земля»
AGL	Above Ground Level	Над уровнем земли
AGN1S	Azimuth Guidance Nose-in-Stand	Азимутальное наведение ВС носом на стоянку
АН	Alert Height	Высота сигнализации
АНР	Army Heliport	Военный вертопорт
AIC	Aeronautical Information Circular	Циркуляр аэронавигационной информации
AIP	Aeronautical Information Publication	Сборник аэронавигационной информации
AiRAC	Aeronautical Information Regulation and Control	Регламентирование и контроль аэронавигационной информации (АНИ) – Система заблаговременного уведомления об изменении АНИ по единой таблице дат вступления в силу
AIREP	Air-Report	Донесение. .с борта
AIS	Aeronautical Information Service	Служба аэронавигационной информации
ALA	Authorized Landing-Area	Разрешенная посадочная площадь (площадка)
ALF	Auxiliary Landing Field	Запасная посадочная площадка
ALS	Approach Light System	Система огней подхода
ALSF	Appoach Light System with Sequenced Flashing Lights	Система огней подхода с бегущими проблесковыми огнями
ALT	Altitude	Высота абсолютная
ALTN	Alternate	Запасной (аэродром)
AMA	Area Minimum Altitude	Минимальная абсолютная высота района
AMSL	Above Mean Sea Level	Над средним уровнем моря
AMSS	Aeronautical Mobil-Satellite Service	Авиационная подвижная спутниковая служба
ANGB	Air National Guard Base	Авиабаза (ВВС) национальной гвардии
AОС	Airport Obstacle Chart	Карта препятствий аэропорта
АОЕ	Airport/Aerodrome of Entry	Аэропорт/Аэродром входа
AOR	Area of Responsibility	Район ответственности
APAPI	Abbreviated Precision Approach Path Indicator	Упрощенный указатель траектории точного захода на посадку
АРС	Area Positive Control	Контролируемый район с эшелонированием
АРСН	Approach	Подход, заход на посадку
АРР	Approach Control	Контроль захода на посадку {диспетчерское обслуживание)
APRX	Approximate/ly	Приблизительный/о
APT	Airport	Аэропорт
ARB	Air Reserve Base	Резервная база ВВС
ARFF	Aircraft Rescue and Fire Fighting	Спасание воздушных судов и борьба с пожаром
ARINC	Aeronautical Radio Inc.	Объединение «Аэронавигационное радио»
ARO	ATS Reporting Office	Пункт сообщений ОВД
ARP	Airport Reference Point	Контрольная точка аэропорта
ARR	Arrival	Прибытие
ARSA	Airport Radar Service Area	Радиолокационное обслуживание в районе аэропорта
ARSR	Air Route Surveillance Radar	Маршрутный обзорный радиолокатор
ARTC	Air Route Traffic Control	Управление воздушным движением на трассе
ARTCC	Air Route Traffic Control Center	Центр управления воздушным движением на трассе
ASDA	Accelerate Stop Distance Available	Располагаемая дистанция прерванного взлета
ASE	Altimetry System Error	Погрешность системы измерения высоты
ASIR	Aviation Safety Incident Report	Отчет об инцидентах авиационной безопасности
ASL	Above Sea Level	Над уровнем моря
ASM	Air Space Managment System	Организация воздушного пространства
ASOS	Automated Surface Observation	Автоматизированная система наземного наблюдения (за погодой)
ASR	Airport Surveillance Radar	Обзорный радиолокатор аэропорта
АТА	Actual Time of Arrival	Фактическое время прилета
АТС	Air Traffic Control	Управление воздушным движением
АТСАА	Air Traffic Control Assigned Airspase	Воздушное пространство, контролируемое (службой) УВД
АТСС	Air Traffic Control Center	Центр управления воздушным движением
АТСТ	Air Traffic Control Tower	Вышка управления воздушным движением
ATD	Actual Time of Departure	Фактическое время вылета
ATF	Aerodrome Traffic Frequency	Частота аэродромного движения
ATFM	Air Traffic Flow Management	Управление потоками воздушного движения
ATIS	Automatic Terminal Information Service	Служба автоматической передачи информации в районе аэроузла (аэропорта)
ATM	Air Traffic Managment	Организация воздушного движения
ATS	Air Traffic Service	Обслуживание воздушного движения
AT-VAS1	Abbreviated Tee Visual Approach Slope Indicator	Сокращенный Т-образный указатель визуальной глиссады захода на посадку
ATZ	Aerodrome Traffic Zone	Зона аэродромного движения
AUTH	Authorized	Разрешенный, уполномоченный
AUW	All-up Weight	Полная полетная масса
AUX	Auxiliary	Вспомогательный
AVASI	Abbreviated Visual Approach Slope Indicator	Упрощенный указатель визуальной глиссады захода на посадку
AVBL	Available	Наличный, имеющийся в распоряжении, действующий
AWIB	Aerodrom Weather Information Broadcast	Передача метеоинформации на аэродроме
AWOS	Automated Weather Observing System	Автоматизированная система наблюдения за погодой
AWY	Airway	Воздушная трасса
AZM	Azimuth	Азимут
BARO-VNAV	Barometric-Vertical Navigation	Вертикальная навигация по барометрическому высотомеру ВС
BC	Back Course	Обратный путевой угол (для ILS обратный курсовой луч)
BCM	Back Course Marker	Маркер обратного курсового луча (ILS)
BCN	Beacon	Маяк
BCST	Broadcast	Радиовещание
BDRY	Boundary	Граница
BLDG	Building	Здание
ВМ	Back Marker	Обратный маркер
BRG	Bearing	Пеленг
B-RNAV	Basic Area Navigation	Зональная навигация — основной метод
BS	Broadcast Station (Commercial)	Радиовещательная станция (коммерческая)
BTN	Between	Между
АТС IFR	Flight Plan Clearance Delivery Frequency	Частота передачи диспетчерского разрешения на план полета по ППП
CADIZ	Canadian Air Defense Identification Zone	Канадская зона опознавания ПВО
CALC	Calculator	Калькулятор
CARS	Community Aerodrome Radio	Аэродромная радиостанция связи Station
CAS	Collision Avoidance System	Система предотвращения столкновения
CAT	Category	Категория
Ccw	Counterclockwise	Против часовой стрелки
CDR	Conditional Route	Условный маршрут
CDT	Central Daylight Time	Центральное дневное время (США)
CEIL	Ceiling	Потолок, нижняя граница облачности
CEU	Central Executive Unit	Центральный исполнительный орган
CERAP	Combined Center/Radar Approach Control	Объединенный центр/ Радиолокационное управление заходом на посадку
CFL	Cleared Flight Level	Разрешенный эшелон полета
CFMU	Central Flow Management Unit	Центральный орган организации потоков
CGAS	Coast Guard Air Station	Авиационная станция береговой охраны
CGL	Circling Guidance Lights	Вращающиеся огни наведения
СН	Channel	Канал, линия связи, полоса частот
СН	Critical Height	Критическая высота
CL	Runway Centerline Lights	Осевые огни ВПП
CMNPS	Canadian Minimum Navigation Performance Specification	Канадские технические требования к минимальным навигационным характеристикам
CMV	Converted Met Visibility
CNS	Communication, Navigation and Surveillance	Связь, навигация и наблюдение
СО	County	Округ (США), графство (Англия)
COMM	Communications	Сообщение, связь
COMSND	Commissioned	Введено в эксплуатацию, укомплектовано
CONT	Continuous	Непрерывный, сплошной
COORD	Coordinates	Координаты
СОР	Change Over Point	Точка переключения (частоты)
CORR	Corridor	Коридор
CP	Command Post	Командный пункт
CPDLC	Controller/Pilot data link	Связь «диспетчер/пилот» по линии передачи данных
Cpt	Clearance (Pre-Taxi Procedure)	Разрешение (перед выруливанием)
CRAM	Conditional Route Availability Message	Сообщение о годности условного маршрута
CRP	Compulsory Reporting Point	Пункт обязательного донесения
CRS	Course	Направление полета, заданный путевой угол, заданное направление
C/S	Call Sign	Позывной
CST	Central Standard Time	Центральное стандартное время (США)
СТА	Control Area	Диспетчерский район
CTAF	Common Traffic Advisory Frequency	Общая консультативная частота обслуживания воздушного движения
CTL	Control	Контроль, диспетчерское обслуживание
CTR	Control Zone	Диспетчерская зона
CVFR	Controlled VFR	Контролируемый полет по ПВП
CVSM	Conventional Vertical Separation Minimum	Традиционный минимум вертикального эшелонирования
CW	Clockwise	По часовой стрелке
CWY	Clearway	Полоса свободная от препятствий
D	Day	День
DA	Decision Altitude	Абсолютная высота принятия решения
DA (Н)	Decision Altitude (Height)	Абсолютная (относительная) высота принятия решения
DCT	Direct	Прямо
DECMSND	Decommissioned	Снят с эксплуатации
DEG	Degree	Градус
DER	Departure End of Runway	Взлетный конец ВПП
DEWIZ	Distance Early Warning Identification Zone	Зона раннего опознавания ПВО
DF	Direction Finder (Finding)	Пеленгатор (пеленгование)
DH	Decision Height	Относительная высота принятия решения
DIR	Director	«Наведение» (частота связи)
DiSPL THRESH	Displaced Threshold	Смещенный порог (ВПП)
DIS, DIST	Distance	Расстояние
DLY	Daily	Ежедневно
DME	Distance-Measuring Equipment	Дальномерное оборудование
DOD	Department of Defense	Департамент обороны
DOM	Domestic	Внутренний
DOP	Dilution of Precision	Снижение точности
DR	Dead Reckoning Position	Место, определяемое счислением пути
DTK	Desired Track	Заданный путевой угол
DTW	Dual Tandem Wheel Landing	Шасси — двойной тандем Gear
DVOR	Doppler VOR	Доплеровский VOR
DW	Dual Wheel Landing Gear	Шасси — спаренные колеса
E	East or Eastern	Восток или восточный
EAT	Expected Approach Time	Прёдпологаемое время захода на посадку
ЕСАС	European Civil Aviation Conference	Европейская конференция гражданской авиации
ECOMS	Jeppesen explanation of Common Minimum Specifications	Объяснения «Джеппсен» по общим характеристикам минимумов
EDT	Eastern Daylight Time	Восточное дневное время (США)
EDPS	Flight Data Processing System	Система обработки полетных данных
EET	Estimated Elapsed Time	Расчетное истекшее время
EGPWS	Enhance Ground Proximity Warning System	Система сигнализации об опасности сближения с землей (СРППЗ) с расширенными возможностями
EFAS	Enroute Flight Advisory Service	Консультативное обслуживание полета на мар¬шруте
EFF	Effective	Вступивший в силу, действующий
ELEV	Elevation	Превышение
EMERG	Emergency	Авария, аварийная ситуация
ENG	Engine	Двигатель
ЕОВТ	Estimated off block time	Расчетное время начала движения
EST	Eastern Standard Time	Восточное стандартное время (США)
ЕТА	Estimated Time of Arrival	Расчетное время прибытия
ETD	Estimated Time of Departure	Расчетное время вылета
ETE	Estimated Time Enroute	Расчетное время в пути
ETOPS	Extended Range Operation with two engine airplanes	Полет увеличенной дальности действия ВС с двумя двигателями
EXC	Except	За исключением
F	Condenser Discharge Sequential Flashing Lights/Sequenced Flashing Lights	Газоразрядные бегущие проблесковые огни/Бегущие проблесковые огни
FAA	Federal Aviation Administration	Федеральная авиационная администрация
FAC	Final Approach Course	Направление конечного этапа захода на посадку
FAF	Final Approach Fix	Контрольная точка конечного этапа захода на посадку
FANS	Future Air Navigation System	Комитет IСАО по будущим навигационным системам
FAP	Final Approach Point	Точка конечного этапа захода на посадку
FAR	Federal Aviation Regulation	Федеральные авиационные правила (США)
FAS	Final Approach Segment	Участок конечного этапа захода на посадку
FCP	Final Control Point	Контролируемая точка на последней прямой
FDPS	Flight Data Processing System	Система обработки полетных данных
FDE	Fault Detection and Exclusion	обнаружение неисправностей и исключение
FIC	Flight Information Center	Центр полетной информации
FIR	Flight Information Region	Район полетной информации
FIS	Flight Information Service	Полетно-информационное обслуживание, Служба полетной информации
FL	Flight Level (Altitude)	Эшелон полета (Абсолютная высота)
FLAS	Flight Level Allocation Scheme	Схема распределения эшелонов полета
FLD	Field	Аэродром (грунтовый)
FLG	Flashing	Проблесковый, мигающий
FLP	Flight Plan	План полета
FLT	Flight	Полет, рейс
FM	Fan Marker	Веерный маркер
FMCS	Flight Managment Computer Syatem	Компьютерная система управления полетом
FMS	Flight Management System	Система управления полетом
FPL	Flight Plan (АТС)	План полета (для УВД)
FPM	Feet Per Minute	Футов в минуту
FPR	Flight Planning Requirement	Требования по планированию полета
FREQ	Frequency	Частота
FSS	Flight Service Station	Станция полетного обслуживания
FT	Feet	Футы
FTE	Flight Technical Error	Погрешность, обусловленная техникой пилотирования
FTS	Flexible Track System	Система изменяемых треков
FUA	Flexible Use of Airspace	Гибкое использование воздушного пространства
G	Guards only (radio frequencies)	Только прослушивание (радиочастот)
GA	General Aviation	Авиация общего назначения
GAL	Gallons	Галлоны
GAT	General Air Traffic	Общее воздушное движение
GCA	Ground Controlled Approach (radar)	Заход на посадку по командам с земли (по локатору)
GDOP	Geometric Dilution of Precision	Геометрическое снижение точности
GEO	Geographic or True	Географический или истинный
GLONASS	Global Orbiting Navigation Satellite System	Глобальная орбитальная навигационная спутниковая система
GLS	GNSS Landing System	Посадочная система глобальной навигационной спутниковой системы
GMT	Greenwich Mean Time	Гринвичевское среднее время
GND	Ground Control	Управление наземным движением (диспетчер руления)
GND	Surface of the Earth (either land or water)	Поверхность земли (суши или воды)
GNSS	Global Navigation Satellite System	Глобальная навигационная спутниковая система
GP	Glidepath	Глиссада
GPS	Global Positioning System	Глобальная система определения местоположения
GPWS	Ground Proximity Warning System	Система сигнализации об опасности сближения с землей
GRS	Ground Reference Station	Наземная опорная станция
GRVD	Grooved	Покрытие с желобками
GS	Glide Slope	Глиссада планирования
G/S	Ground Speed	Путевая скорость
GWT	Gross Weight	Общая масса
Н	Non-Directional Radio Beacon ог High Altitude	Ненаправленный радиомаяк или высота в верхнем воздушном пространстве
Н24	24 Hour Service	Круглосуточная работа
НАА	Height Above Airport	Относительная высота над аэро-дромом
HAT	Height Above Touchdown	Относительная высота над зоной приземления
НС	Critical Height	Критическая высота
HDG	Heading	Курс
HDOP	Horizontal Dilution of Precision	Снижение точности определения местоположе¬ния по горизонтали
HEL	Helicopter	Вертолет
HF	High Frequency (3 — 30 MHz)	Высокая частота (3 — 30 МГц)
НОТ	Height	Высота относительная
HI	High (altitude)	Большая (абсолютная) высота, верхнее воздушное пространство
HI	High Intensity (lights)	Высокая интенсивность (огней)
HIALS	High Intensity Approach Light System	Система огней подхода высокой интенсивности
HIRL	High intensity Runway Edge Lights	Посадочные боковые огни ВПП высокой интенсивности
HIWAS	Hazardous inflight Weather Advisory Service	Консультативное оповещение об опасных явлениях погоды в полете
HJ	Sunrise to Sunset	От восхода до захода СоЛнца
HN	Sunset to Sunrise	От захода до восхода Солнца
НО	By Operational Requirements	По эксплуатационным требованиям
hPa	Hectopascal (one hectopascal = one millibar)	Гектопаскаль (1 гектопаскаль = 1 миллибару)
HR	Hours (period of time)	Часы (период времени)
HS	During Hours of Scheduled Operations	В часы полетов по расписанию
HSI	Horizontal Situation Indicator	Индикатор горизонтальной обстановки, плановый навигационный прибор
HST	High Speed Taxi-way Turn-off	Скоростная РД для сруливания
HTZ	Helicopter Traffic Zone	Зона полетов вертолетов
HWP	Holding Way Point	Точка зоны ожидания (RNAV)
Hz	Hertz (cycles per second)	Герц (периодов в секунду)
I	Island	Остров
IAC	Instrument Approach Chart	Карта захода на посадку по приборам
IAF	Initial Approach Fix	Контрольная точка начального этапа захода на посадку
IAP	Instrument Approach Procedure	Процедура (схема) захода на посадку по приборам
IAS	Indicated Airspeed	Приборная воздушная скорость
IBN	identification Beacon	Опознавательный маяк
ICAO	International Civil Aviation Organization	Международная организация гражданской авиации (ИКАО)
IDENT	Identification	Опознавание
IF	Intermediate Fix	Контрольная точка промежуточного (этапа захода на посадку)
IFF	Identification Friend or Foe	Опознавание «свой — чужой»
IFR	Instrument Flight Rules	Правила полетов по приборам
IGS	Instrument Guidance System	Система наведения по приборам
ILS	Instrument Landing System	Система посадки по приборам
IM	inner Marker	Ближний (внутренний) маркер/привод
IMC	Instrument Meteorological Conditions	Приборные метеорологические условия
IMS	Integrity Monitoring System	Система контроля целостности
IMTA	Intensive Military Training Area	Район интенсивных военных тренировочных по¬летов
INBD	Inbound	(Полет) «на» . .., прибывающий, прилетающий
INDEFLY	Indefinitely	Неопределенно
IN or INS	Inches	Дюймы
INFO	Information	Информация
INOP	Inoperative	Недействующий
INP	If Not Possible	Если невозможно
INS	Inertial Navigation System	Инерциальная навигационная система
INT	Intersection	Пересечение
INTL	International	Международный
IORRA	Indian Ocean Random RNAV Area	Произвольный район зональной навигации Индийского океана
IR	Instrument Restricted Controlled Airspace	Контролируемое воздушное пространство, ограниченное для полетов по ППП
IS	islands	Острова
ITWS	Integrated Terminal Weather System	Объединенная метеорологическая система аэроузла
I/V	Instrument/Visual Controlled Airspace	Контролируемое воздушное пространство для полетов по ППП/ПВП
JAA	Joint Aviation Authorities	Объединенная авиационная администрация (стран Западной Европы)
JAA AMC	JAA Acceptable Means of Compliance	Приемлемые средства соответствия JAA
JAR	Joint Aviation Requirements	Объединенные авиационные требования
JBD	James Brake Decelerometer (Canada)	Измеритель коэффициента сцепления по Джеймсу (Канада)
JBI	James Brake Index (Canada)	Индекс коэффициента сцепления по Джеймсу (Канада)
KGS	Kilograms	Килограммы
kHz	Kilohertz	Килогерц
KIAS	Knots Indicated Airspeed	Приборная скорость в узлах
КМ	Kilometers	Километры
KMH	Kilometer(s) per Hour	Км/ч
KT	Knots	Узлы
KTAS	Knots True Airspeed	Истинная воздушная скорость в узлах
L	Locator (Compass)	Привод
LAA	Local Airport Advisory	Консультативное обслуживание в местном аэропорту
LAAS	Local Area Augmentation System	Система функционального дополнения с ограничейной зоной действия
LAHSO	Land and Hold Short Operations	Операции: посадка и кратковременное ожидание
LAL	Level Alarm Low – как вариант
LAT	Latitude	Широта
LBCM	Locator Back Course Marker	Приводная радиостанция обратного курса (по¬садки) с маркером
LAD GNSS	Landing GNSS	Локальная дифференциальная GNSS
IBM	Locator Back Marker	Приводная радиостанция обратного маркера
LBS	Pounds (Weight)	Фунты (вес)
LC	Landing Chart	Карта посадки
LCG	Load Classification Group	Классификационная группа нагрузки
LCN	Load Classification Number	Классификационное число нагрузки
Lctr	Locator (Compass)	Привод
LDA	Landing Distance Available	Располагаемая посадочная дистанция
LDA	Localizer type Directional Aid	Средство наведения типа курсового маяка
LDI	Landing Direction Indicator	Указатель направления посадки
LDIN	Lead-in Light System	Система ведущих (посадочных) огней
LGTH	Length	Длина
LH	Left Hand	Левостороннее (движение)
LIM	Locator Inner Marker	Привод внутреннего маркера
LLWAS	Low Level Wind Shear Alert System	Система предупреждения о сдвиге ветра на низких высотах
LMM	Locator Middle Marker	Привод среднего маркера
LNDG	Landing	Приземление, посадка
LNAV/VNAV	Lateral Navigation/Vertical Navigation	Навигация по направлению / Навигация по вертикали
LO	Locator at Outer Marker Site	Приводная радиостанция, совмещенная с вне¬шним маркером
LOC	Localizer (Jeppesen abbreviation)	Курсовой радиомаяк (аббревиатура «Джеппсен»)
LOG	Locator (ICAO abbreviation, not used by Jeppesen)	Приводная радиостанция (аббревиатура ИКАО не используется «Джеппсен»)
LOM	Locator Outer Marker	Привод внешнего маркера
LONG	Longitude	Долгота
LSALT	Lowest Safe Altitude	Наименьшая безопасная абсолютная высота
LT	Local Time	Местное время
LTS	Lights	Огни
LVP	Low Visibility Procedures	Процедуры при низкой видимости
М	Meters	Метры
МАА	Maximum Authorized Altitude	Максимальная разрешенная абсолютная вы¬сота
MAG	Magnetic	Магнитный
MALS	Medium Intensity Approach Light System	Система огней подхода средней интенсивности
MALSF	Medium Intensity Approach Light System with Sequenced Flashing Lights	Система огней подхода средней интенсивности с бегущими проблесковыми огнями
MALSR	Medium Intensity Approach Light System with Runway Alingment Indicator Lights	Система огней подхода средней интенсивности с индикатором огней створа ВПП
MAP	Missed Approach Point	Точка ухода на повторный заход
MASPS	Minimum Aircraft System Performance Specification	Технические требования к минимальным характеристикам бортовых систем
МАХ	Maximum	Максимум, максимальный
MB	Millibars	Миллибары
МВОН	Minimum Break Off Height	Минимальная относительная высота отключения (автоматики на переход к ручному пилотированию)
MBZ	Mandatory Broadcast Zone	Зона обязательной передачи (радиосигнала)
МСА	Minimum Crossing Altitude	Минимальная абсолютная высота пересечения
MCAF	Marine Corps Air Facility	Аэронавигационное средство морской пехоты
MCAS	Marine Corps Air Station	Авиабаза морской пехоты
МСОМ	Multicom	Оперативное обслуживание для определенного круга абонентов, используемое с целью обес¬печения необходимой связи при использова¬нии ВПП для уменьшения задержки и увеличе¬ния ее пропускной способности
МСТА	Military Controlled Airspace	Воздушное пространство, контролируемое военными
MDA	Minimum Descent Altitude	Минимальная абсолютная высота снижения
MDA (H)	Minimum Descent Altitude (Height)	Минимальная абсолютная (относительная) высота снижения
MDT	Mountain Daylight Time	Горное дневное время (США)
MEA	Minimum Enroute Altitude	Минимальная абсолютная высота по маршруту
МЕНТ	Minimum Eye Height Over Threshold	Минимальная высота глаза (наблюдателя) над порогом (ВПП)
MEML	Memorial	Мемориал, мемориальный
МЕТ	Meteorological	Метеорологический
MF	Mandatory Frequency	Обязательная частота
МНА	Minimum Holding Altitude	Минимальная абсолютная высота ожидания
MHz	Megahertz	Мегагерц
Ml	Medium Intensity (lights)	Средней интенсивности (огни)
MiALS	Medium Intensity Approach Light System	Система огней подхода средней интенсивноети
MIL	Military	Военный
MIM	Minimum	Минимум, минимальный
MIN	Minute	Минута
MIRL	Medium Intensity Runway Edge Lights	Посадочные боковые огни ВПП средней интенсивности
MKR	Marker Radio Beacon	Маркерный радиомаяк
MLS	Microwave Landing System	Микроволновая система посадки
MLW	Maximum Certificated Landing Weight	Максимальная сертифицированная посадочная масса
MM	Middle Marker	Средний маркер
MNPS	Minimum Navigation Performance Specifications	Технические требования к минимальным навигационным характеристикам
МОА	Military Operation Area	Район военных операций
МОСА	Minimum Obstruction Clearance Altitude	Минимальная абсолютная высота пролета препятствий
MOPS	Minimum Operational Performance Specification	Стандарты минимальных эксплуатационных характеристик
MORA	Minimum Off-Route Altitude (Grid or Route)	Минимальная абсолютная высота вне маршрута (сеточная или маршрутная)
MPS	Meters per Second	Метры в секунду
MPW	Maximum Permitted Weigh	Максимальный разрешенный вес
MRA	Minimum Reception Altitude	Минимальная абсолютная высота приема (сиг¬нала)
MSA	Minimum Safe Altitude	Минимальная безопасная абсолютная высота
MGS	Message	(Вывод) сообщение
MSL	Mean Sea Level	Средний уровень моря
MST	Mountain Standard Time	Горное стандартное время (США)
МТА	Military Training Area	Район военных тренировочных полетов
MTAF	Mandatory Traffic Advisory Frequency	Предписанная частота для консультативного движения
МТСА	Minimum Terrain Clearance Altitude	Минимальная безопасная абсолютная высота над рельефом местности
МТМА	Military Terminal Control Area	Военный узловой диспетчерский район
MTOW	Maximum Take-off Weight	Максимальная взлетная масса
MTWA	Maximum Total Weight Authorized	Максимальная разрешенная общая масса
MUN	Municipal	Муниципальный (городской)
MVA	Minimum Vectoring Altitude	Минимальная абсолютная высота векторения
MVFR	Marginal VFR	ПВП в особых условиях
N	Night, North or Norhern	Ночь, север или северный
NA	Not Authorized	He разрешено
NAAS	Naval Auxiliary Air Station	Военно-морская вспомогательная авиастанция
NADC	Naval Air Development Center	Авиационный научно-исследовательский центр ВМС
NAEC	Naval Air Engineering Center	Авиационно-технический центр ВМС
NAF	Naval Air Facility	Военно-морские авиационные навигационные (радио)средства
NALF	Naval Auxiliary Landing Field	Вспомогательное посадочное поле ВМС
NAP	Noise Abatement Procedure	Процедура уменьшения шума
NAR	North American Routes	Северо-Американские маршруты
NAS	Naval Air Station	Авиастанция ВМС
NAT	North Atlantic Traffic	Полеты в Северной Атлантике
NAT/OTS	North Atlantic Traffic/Organized Track System	Полеты в Северной Атлантике / Система организованных треков
NATL	National	Национальный
NAV	Navigation	Навигация
NAVAID	Navigational Aid	Навигационное средство
NCA	Northern Control Area	Северный диспетчерский район
NCRP	Non-Compulsory Reporting Point	Пункт необязательного доклада
NDB	Non-Directional Beacon / Radio Beacon	Ненаправленный радиомаяк / Радиомаяк
NE	Northeast	Северо-восток
NM	Nautical Mile(s)	Морская миля(и)
No	Number	Число, номер
NoPT	No Procedure Turn	Процедура стандартного разворота не требуется
NOTAM	Notices to Airmen	Извещения для летчиков
NSE	Navigation System Error	Погрешность навигационной системы
NW	Northwest	Северо-запад
NWC	Naval Weapons Center	Военно-морской центр вооружения
О/А	On or About	«На» или «около»
ОАС	Oceanic Area Control	Диспетчерское обслуживание в океаническом Районе
OAT	Operational air traffic	Оперативное воздушное движение
OBS	Omnidirectional Bearing Selected	Заданное (выбранное) направление (пеленг) выхода в пункт маршрута
ОСА	Oceanic Control Area	Океанический диспетчерский район
ОСА (Н)	Obstacle Clearance Altitude (Height)	Абсолютная (относительная) высота пролета препятствий
OCL	Obstruction Clearance Limit	Запас высоты пролета препятствия
OCNL	Occasional	Нерегулярный
ОСТА	Oceanic Control Area	Океанический диспетчерский район
ODALS	Omni-Directional Approach Light System	Система всенаправленных огней подхода
ОМ	Outer Marker	Внешний маркер
OPS	Operations or Operates	Работы, эксплуатации, полеты или работает, эксплуатирует, выполняет полет
O/R	On Request	По запросу
О/Т	Other Times	В другое время
OTS	Out-of-Service	Неисправен, не работает, обслуживание не предоставляется
OTS	Organized Track System	Система организованных треков

Общий анализ мочи при цистите

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

Основные симптомы цистита

частое болезненное мочеиспускание
боль в паховой области
ложные позывы к мочеиспусканию
мутная моча, возможно появление примеси крови
внезапное начало симптомов
повышение температуры тела

Какой анализ мочи нужен при цистите

При подозрении на цистит сначала обязательно нужно сдать общий анализ мочи (ОАМ). В результатах ОАМ при цистите будет выявлено повышенное содержание лейкоцитов, бактерий, может встречаться повышенное содержание эритроцитов и белка.

Дополнительно лечащий врач может рекомендовать провести бактериальный посев мочи с определением антибиотикочувствительности к выявленным патогенным микроорганизмам, ПЦР диагностику на заболевания, передающиеся половым путем, ряд исследований на диагностику вирусных инфекций (так как не всегда причиной цистита являются бактерии).

Из инструментальных исследований врач может направить пациента на УЗИ почек, КТ/МРТ малого таза для исключения опухолей и камней в мочевыделительной системе, заболеваний почек и предстательной железы у мужчин.

Профилактика обострений цистита

Регулярно проводить тщательный туалет наружных половых органов
Использовать барьерные способы контрацепции
Своевременно проводить лечение гинекологических и урологических заболеваний
В течение ближайшего времени после полового акта помочиться

Подготовка к сдаче ОАМ при цистите

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

Исключить прием мочегонных препаратов в течение 48 часов до сбора мочи (согласовывается с лечащим врачом).

Собирать мочу нужно до начала антибиотикотерапии.

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

Женщины во время менструации перед сбором мочи должны поставить во влагалище тампон и сообщит лечащему врачу, что анализ проведен во время менструации.

Как правильно собирать анализ мочи при цистите

В стерильный контейнер собирается средняя порция мочи при первом утреннем мочеиспускании (первая и последние порции сливаются в унитаз).

Возможен сбор мочи в любое время в течение дня по предварительному согласованию с лечащим врачом.

Во время сбора мочи желательно не касаться контейнером тела.

Перед началом мочеиспускания женщинам нужно развести пальцами половые губы пальцами, чтобы с кожи наружных половых органов в мочу не попали посторонние примеси.

Объем мочи для исследования должен составлять ¾ объема контейнера. Минимальный объем мочи для исследования составляет 30 мл.

Доставить контейнер с мочой в медицинский офис желательно в течение 2-х часов после сбора биоматериала.

Что показывает анализ мочи при цистите

ОАМ позволяет увидеть общую картину воспаления. Для постановки диагноза во внимание в первую очередь учитываются жалобы пациента. ОАМ нужен для подтверждения диагноза, основанного на клинической картине, так как болезненность при мочеиспускании может встречаться у пациентов с нарушением нервной регуляции акта мочеиспускания, без цистита.

Расшифровка общего анализа мочи при цистите

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

В медицинской компании «LabQuest» Вы можете получить персональную консультацию врача службы «Doctor Q» по расшифровке результатов исследования мочи во время приема или по телефону.

Цвет. В норме цвет желтый различной насыщенности. Он может меняться при употреблении некоторых продуктов и приеме ряда лекарственных препаратов. Белесый, темно-бурый или другой нехарактерный цвет указывает на наличие патологии. Моча должна быть прозрачной.

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

Реакция мочи. В норме рН составляет 5-7 (слабокислая реакция). Повышенная кислотность характерна для лихорадочных состояний, почечной недостаточности, сахарного диабета и других патологий. Щелочная реакция наблюдается при хронических инфекционных заболеваниях.

Показатели плотности используются для оценки функций почек. В течение суток удельный вес мочи колеблется.

Белок в моче (протеинурия) в норме отсутствует. Его появление – маркер наличия различных заболеваний (воспалительные инфекционные заболевания мочевыводящих путей, патология почек и другие). Также белок определяется в моче после сильного переохлаждения, высокой физической нагрузки.

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

Билирубин выявляется при гепатитах, циррозе, механической желтухе и других патологических состояниях, связанных с повреждениями печени.

Уробилиноген в высокой концентрации указывает на поражения печени, гемолитическую желтуху, заболевания ЖКТ. Повышенное количество кетоновых тел свидетельствует о нарушении белкового, углеводного или липидного обмена. Нитриты указывают на инфекцию мочевыводящих путей.

Плоский эпителий – это поверхностно расположенные клетки кожи наружных половых органов. Обнаружение его в моче диагностического значения не имеет.

Переходный эпителий находится в почках, мочеточниках, мочевом пузыре и верхнем отделе мочеиспускательного канала. Единичные клетки могут встречаться в осадке мочи у здоровых людей. В большом количестве обнаруживаются при интоксикации, после инструментальных вмешательств на мочевыводящих путях, при желтухах, почечнокаменной болезни и хроническом цистите.

Почечный эпителий у здоровых людей в микроскопии осадка не встречается. Обнаруживается у пациентов с нефрозами и нефритами.

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

Лейкоциты присутствуют в моче здоровых людей. Повышенное количество лейкоцитов в моче у женщин может встречаться при контаминации мочи влагалищными выделениями. Высокое содержание лейкоцитов в моче бывает при пиелоциститах, пиелонефритах, при лихорадке различного генеза, инфекциях мочеполовых путей.

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

Слизь выполняет защитную функцию, выделяется специальными клетками мочеполовой системы. В норме ее содержание в моче незначительное, при воспалительных процессах может увеличивается.

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

Бактерии указывают на бактериальную инфекцию мочевыделительного тракта. Но могут встречаться при контаминации мочи бактериями с кожных покровов и из влагалищных выделений.

Где можно сдать анализ мочи при цистите

Сдать ОАМ при цистите можно в ближайшем медицинском офисе лаборатории «LabQuest». Список медицинских офисов, где принимается биоматериал, представлен в разделе «Адреса и время работы».

158876 просмотров

Автор-врач: Савченко Светлана Петровна

Эксперт в области лабораторной диагностики, организации здравоохранения, диагностики и лечения заболеваний терапевтического профиля.

Дата публикации статьи: 12.01.2021

Обновлено: 19.08.2022

WMS система управления складом — что это

Главная
Отрасли
WMS

WMS-система управления складом (Warehouse Management System) – это мощный программный инструментарий, предназначенный для автоматизации управления процессами склада или работы складского комплекса. Функционал системы управления складом позволяет пользователю централизованно, под управлением WMS-программы, с применением мобильных и голосовых терминалов выполнять складские операции. Эксплуатация склада с внедренной WMS-системой осуществляется просто и эффективно, позволяя свести к минимуму потери при выполнении складских операций.

В этой статье мы расскажем о WMS системе управления складом и о всех критически важных бизнес-процессах, связанных с управлением работой склада.

Рассмотрим такие аспекты управления логистикой склада, как:

Что такое WMS-система управления складом;
Какие преимущества внедрения системы управления складом;
Функционал WMS-системы управления складом;
Как выбрать систему управления складом.

Что такое WMS-система управления складом?

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

Преимущества внедрения WMS-системы управления складом:

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

Рассмотрим основные преимущества:

Наличие исчерпывающих актуальных данных для принятия быстрых решений
Система управления складом отражает всю информацию о товарном запасе и работает в режиме реального времени. Т.е. вы видите и оцениваете текущую ситуацию на складе и можете быстро выявлять факторы повышенного риска, например, кража, повреждение товара и т.п. Вы можете быстрее оценивать продуктивность работы вашего персонала, и знать точно о времени выполнения той или иной операции, и, как следствие, какие процессы складской логистики у вас «проседают» и требуют доработок.
Повышение скорости выполнения заказов
Текущая высококонкурентная среда требует от поставщиков сокращения времени выполнения заказа до дня или даже нескольких часов, и это уже становится нормой в работе торгового предприятия. Система управления складом будет тем инструментом, который позволит усовершенствовать процессы и вывести доставку заказов на новый уровень. Ваша команда, работающая под управлением WMS-системы с применением мобильных терминалов или других устройств/систем, позволяющих автоматизировать выполнение ручных операций, сможет быстрее собирать и упаковывать заказы, что позволит значительно уменьшить время обработки и доставки товаров.
Снижение затрат на складскую обработку
Если сократить время выполнения складских операций, например, отбор, упаковку заказов или приемку, а также других процессов, то это неизбежно повлечет за собой снижение ваших затрат на складскую обработку товара. Это достаточно просто проверить. Можно рассчитать текущую стоимость обработки каждого заказа при работе без системы управления складом и сравнить с данными после завершения проекта внедрения. И тогда вы сможете увидеть, какая окупаемость будет достигнута.
Минимизация ошибок
Система управления складом и штрих-кодированная продукция существенно сокращают время на обработку товара и снижают риск возникновения ошибок. Под управлением WMS-системы сотрудники склада сканируют штрих-код товара во время выполнения всех складских процессов: отбора, упаковки, отгрузки, приемки и т.д. Система управления складом инициирует всю активность персонала, при неверных операциях, например, сканировании другого товара, предупреждает об ошибочном действии, автоматически ведет учет товара, в режиме реального времени передает данные в учетную систему. Такая организация работы склада не только позволяет значительно сократить ошибки, но и повысить степень удовлетворенности ваших заказчиков, снизить количество отрицательных отзывов.
Экономия времени
Система управления складом сокращает время выполнения складских операций, особенно это важно для сборки и доставки заказов. Инвентаризация товара также выполняется быстрее, без ошибок, в режиме реального времени, без остановки работы склада. Терминалы сбора данных, считывающие штрих-код с продукции и передающие данные в систему для склада в режиме on-line также сокращают время проведения инвентаризации. Чтобы узнать о дополнительных преимуществах работы склада под управлением WMS-системы, прочитайте эту статью

Несколько простых советов по внедрению системы штрихкодирования:

Для внедрения на складе системы штрихкодирования требуется больше усилий, чем просто наклеить этикетки со штрих-кодом на товар и начать использовать радио-терминалы. Также вам нужно организовать эффективную работу склада и оптимизировать все складские процессы.

При планировании работы склада нужно обратить внимание на следующие моменты :

Оптимизируйте размещение товаров на складе;
Самые востребованные товары размещайте ближе к упаковочной зоне;
Выделите наиболее доступные зоны для высоко оборачиваемых продуктов в пиковый сезон, во время распродаж;
Штрих-коды располагайте в удобном для сканирования положении.

Функционал WMS-системы управления складом:

WMS-система управления складом применяется для автоматизации работы склада, что обеспечивает управление бизнес-процессами и контроль выполнения складских операций (приемка, перемещение, хранение, комплектация, отгрузка, и т.д.), Программа интегрируется с учетными программами предприятия, обеспечивает полную прозрачность данных в цепочке поставок всей компании.

WMS-система управления складом Logistics Vision Suite, представляемая «АНТ Технолоджис», обладает высокой эффективностью, широким функционалом, имеет неоспоримые конкурентные преимущества, выражаемые в быстрой адаптации под требования склада.

Адаптивность и широта настроек позволяет владельцу создать логистическую систему, решающие индивидуальные потребности для управления логистическим бизнесом. LVS подходит для крупных и средних компаний с интенсивными процессами товарооборота. Подробно→

Logistics Vision Suite управляет работой складов различной специализации: V7склад, Kerama-Marazzi, «МГЛ МЕТРО ГРУП ЛОГИСТИКС», STS Logistics, Smart Logistic Group, Логистическое Агентство 20А, HOFF, «Авеста Фармацевтика», «МИНИМАКС», Simple, «Группа Полипластик», Incity, «Алвиса», «Айсберри» и другие. Смотреть всех клиентов →

Рассмотрите систему управления складом Logistics Vision Suite как эффективное решение для оптимизации работы вашего склада. Отправьте запрос нашему специалисту [email protected]

Узнать, нужна ли WMS вашему бизнесу →

Приемка товара

Система WMS управляет работой склада по предварительно настроенным бизнес-процессам, соблюдение которых является обязательным условием при выполнении всех операций, в том числе при приемке товара. Процесс приемки товара может быть настроен под требования пользователей системы, но основная задача обеспечить приемку товара с минимальными ошибками, экономя при этом время при выполнении операции.

Учет товара

Система для склада ведет учет товара, предоставляет пользователям актуальную информацию о его количестве, позволяет минимизировать затаривание склада ненужными остатками. Экономия складского пространства и бесперебойная работа логистики склада достигается за счет оптимального распределения и хранения запасов.

Оптимизация процесса хранения

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

Управление персоналом

Централизованное управление складом сокращается необходимость в содержании персонала в большом количестве. Оптимизация рабочего фонда становиться возможной, в том числе, за счет сокращения частоты инвентаризации товара. WMS программа позволяет производить инвентаризацию товара без вмешательства в повседневную работу склада. Сокращение расходов на оплату труда позволяет снизить текущие (операционные) расходы на содержание склада и повысить эффективность работы всего предприятия. Измерение ключевых показателей эффективности работы склада (KPI склада) повышает эффективность работы, позволяет измерять показатели эффективности, проверять выполнение и результативность работы, формировать форму отчетности, настраивать систему мотивации и нормы оплаты труда.

Документооборот

WMS-система управления складом способна автоматизировать все процессы, устраняя необходимость ведения бумажного документооборота, требующего значительных ресурсов. Пользователи могут иметь общий доступ к базе данных, обеспечить работников необходимой информацией для быстрой и качественной работы.

Комплектация и отгрузка

Программа управления складом обеспечивает качественную сборку заказов, это означает, что процесс сборки будет выполнен по складским стандартам, методам FIFO, FEFO, FPFO и LIFO. WMS С такой системой ваши заказы будут правильно собраны и доставлены по верному адресу в необходимое время.

Обслуживание клиентов

WMS-система управления складом повышает качество обслуживания клиентов за счет быстрой и безошибочной обработки заказов поклажедателей и своевременной доставки. Высокое качество обслуживания повышает конкурентоспособность компании, позволяет формировать лояльность текущих заказчиков и привлекать новых клиентов.

Управление складом и контроль

Для предприятий, которым необходимы расширенные возможности контроля, программа предлагает отслеживать товар по различным характеристикам: серийные номера, сроки годности, товарные коды и т. п. Вопросы по возвратам и условиям гарантии качества товара быстро решаются путем возможности отслеживания каналов поставок.

Отчетность

Лучшие системы управления складом (Warehouse Management Systems), в число которых входит Logistics Vision Suite, позволяют так же просто использовать базы данных, как и Microsoft SQL, что обеспечивает возможность формирования отчетов даже в стандартных версиях решений. Но WMS-системы обладают преимуществом, они позволяют менять способы представления данных. На основании имеющейся информации можно формировать различные отчеты:

эффективность использования складских площадей;
необходимость увеличения или сокращения складских площадей;
работоспособность каждого работника склада;
оптимизация количества персонала;
анализ финансовых затрат на основании данных об объеме хранения и количества выполненных операций;
и др.

Как выбрать WMS-систему управления складом:

На рынке представлены различные типы WMS-систем, есть простые коробочные решения, а есть сложные комплексные системы управления складом, подходящие для крупных складов. Система управления складом Logistics Vision Suite относится к классу комплексных информационных систем, с полным набором функций и возможностью значительной модификации комплекса выполняемых задач в соответствии со спецификой и потребностями логистики компании, выполнение требований контролирующих органов: интеграция с государственными системами цифровой маркировки и прослеживаемости товаров «Честный Знак», ЕГАИС, «Меркурий».

Чтобы выбрать систему для управления складом необходимо учесть ряд факторов, некоторые из которых мы рассмотрим:

Функциональность:

Размер склада: крупным складам необходимы системы управления с более развитым функционалом, чем небольшим складским хозяйствам. Это объясняется более высокой сложностью выполняемых операций и большим объемом технологических процессов крупного склада. Чем крупнее склад, те сложнее вычислить стоимость одной транзакции, поэтому в этом случае, необходима организация детального отслеживания каждой складской операции.

Потребности клиента:

WMS Цена:

Полезная информация

История успеха

Склад «Метро Груп Логистикс» работает под управлением WMS Logistics Vision Suite & Vocollect Voice

Новости

Все новости

Новости партнеров

Все новости партнеров

Ваш консультант:

Андрей Хвостиков
+7 (495) 785-72-28

Скачать буклет

Наши клиенты

Награды и достижения

Условия поставки FCA (Free Carrier) Инкотермс 2010 (актуально на 2017)

Содержание статьи:

Что означает FCA: расшифровка
Дополнительная терминология для FCA
Базис и условия поставки FCA
Распределение рисков и обязанностей
- Обязанности и риски продавца (поставщика)
- Обязанности и риски покупателя
- Переход права собственности и рисков
- Кто оформляет CMR?
Что такое франко-перевозчик?
Договор поставки на условиях FCA
Что такое цена на условиях FCA?

Перейти на список всех условий Инкотермс

В сфере международной торговли действуют Правила Инкотермс в редакции 2010 года – правила исполнения обязательств сторонами договора. До 1 января 2011 года при составлении соглашения о купле-продаже участники процесса ВЭД руководствовались Правилами Инкотермс 2000 года. В новой редакции появились два новых понятия: DAT и DAP, которые заменили практиковавшиеся до 2011 года термины DAF, DES, DEQ и DDU. Следовательно, в Инкотермс 2010 стало меньше правил: 11 вместо 13. Это – EXW, FCA, CPT, CIP, DAT, DAP, DDP, применяющиеся независимо от вида транспорта для перевозки, и FAS, FOB, CFR и CIF применительно к морским перевозкам и транспортировке грузов на внутреннем водном транспорте.

В данной статье мы рассмотрим термин FCA – Франко перевозчик.

Что означает FCA: расшифровка

Термин FCA используется при перевозке и расшифровывается как Free Carrier. Данное словосочетание дословно можно перевезти как «бесплатный» или «свободный» «перевозчик». При составлении договора применяется словосочетание «Франко перевозчик» (… название места). Если выразить простыми словами, термин означает, что обязательства продавца по отношению к товару сохраняются только до передачи им товара перевозчику, выбранному покупателем. Свобода в выборе покупателем логистической компании ничем не ограничена.

Франко – это место, где ответственность за сохранность и транспортировку товара полностью перекладывается на плечи покупателя.

Под словом «Перевозчик» можно понимать лицо, которое согласно договору поставки продукции обеспечит транспортировку груза на определенном контрактом виде транспортного средства или его комбинации.

В условиях и порядке поставки товара указывается, что «поставка товара по контракту осуществляется на условиях FCA – Free carrier/Франко перевозчик – «Инкотермс 2010». Также указывается пункт передачи товара, например, ООО «ЧИСТО» при экспорте моющих средств для кофемашин в Китай могло бы обозначить: «FCA д. 31, ул. Бестужева, г. Владивосток, Приморский край, Российская Федерация, Инкотермс 2010».

Дополнительная терминология для FCA

Обозначенное в контракте место поставки разграничивает обязательства продавца и покупателя по погрузке и разгрузке товара. Так, при поставке на территории, принадлежащей поставщику, ответственность за погрузочно-разгрузочные работы ложится на продавца, если в ином месте, то на покупателя. Разграничение обязанностей происходит с использованием дополнительных терминов. Так, когда нужно перевезти груз, объем которого полностью занимает все пространство вагона, машины, баржи, иного транспортного средства, то в договоре указывается:

FOT (free on truck) (при перевозке авто).
FIW (free in wagon) (ж/д перевозка).
FIB (free into barge) (перевозка на барже).

Когда требуется консолидация груза, то можно согласовать с продавцом организацию доставки товара до терминала, склада, порта, который указывается продавцом. И тогда применяется следующая терминология:

FT (free terminal) (терминал).
FOR (free on rail) (станция отправления).
FFB (free ferry berth) (паромный причал).

Пожалуйста, помогите сделать эту статью лучше.
Ответьте всего на 3 вопроса.

Базис и условия поставки FCA

Базисные условия FCA по Инкотермс 2010 создают существенные условия покупателю для возможности выбора транспортного средства для доставки груза, построения логистической цепочки.

Перевозчиком может стать транспортная компания или любое доверенное лицо покупателя, с кем заключен контракт на оказание логистических услуг.

Покупатель может выбрать мультимодальную доставку, автомобильную, ж/д, на воздушном судне, поездом и т.д.

Если отгрузка происходит непосредственно на складе продавца, то последний несет все расходы по погрузке. Когда в качестве франко-места определены терминал или иное место, не принадлежащее на праве собственности или аренды поставщику, то расходы на погрузку должен оплатить покупатель.

В обязанность продавца вменена очистка груза от экспортных пошлин: условия FCA предполагают сдачу товара с приложением подтверждающего документа. После передачи груза ответственность за товар несет покупатель.

Таможенные расходы (на импорт) в стране получения также осуществляет покупатель.

Распределение рисков и обязанностей

Обязанности продавца и покупателя по правилам FCA четко разграничены.

Обязанности и риски продавца (поставщика)

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

Получить лицензию для экспорта продукции, иное свидетельство, выполнить таможенные формальности при вывозе, все это – задачи продавца.

Отсутствуют обязательства по страхованию и фрахту груза. Продавцу необходимо только предоставить товар компании-перевозчику в указанном в договоре месте, в установленные сроки и время. Поставку можно считать выполненной, если соблюден ряд условий:

Товар загружен в транспорт компании-перевозчика в помещении, принадлежащем продавцу.
Товар в транспортном средстве продавца готов к отгрузке в транспорт перевозчика, если франко-место расположено за территорией, собственником которой является продавец.

Продавец несет расходы, связанные с товаром до его поставки покупателю, а также оплачивает экспортные пошлины, налоги, иные сборы.

О поставке товара продавец должен известить покупателя должным образом.

Доказательствами поставки являются транспортные документы, в том числе в электронном виде, если стороны договора пришли к соглашению об использовании средств электронной связи.

Расходы на упаковку ложатся на продавца. Она должна быть надлежаще маркирована.

Продавец может оказать содействие покупателю в получении иных документов, которые нужны для импорта товара. Но только за счет последнего.

Обязанности и риски покупателя

Основная обязанность покупателя – в оплате полной стоимости товара согласно договору купли-продажи.

Кроме этого, будут следующие денежные расходы:

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

Покупатель обязан принять поставку товара, если она выполнена согласно договору.

Покупатель извещает должным образом продавца о наименовании перевозчика, способе транспортировки, дате и сроках поставки товара для передачи перевозчику.

Кроме этого, покупателю за 10 дней до поставки товара нужно будет предоставить перевозчику следующие данные:

Наименование товара, его объем;
Полное и краткое наименование компании-грузоотправителя;
Дата и время загрузки, точный адрес места загрузки, например, склад продавца;
Полное наименование компании-грузополучателя и краткое;
Точный адрес грузополучателя. При отсутствии номера квартиры об этом должна быть соответствующая пометка;
Коды грузополучателя;
Коды железнодорожных станций при доставке ж/д путем;
Иные сведения, которые позволят перевозчику уложиться по срокам доставки.

Переход права собственности и рисков

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

До этого момента все риски за товар несет продавец, после – покупатель.

В случае, когда покупатель не смог вовремя вывезти товар, то и переход рисков осуществляется с даты, когда он должен был организовать перевозку груза.

Кто оформляет CMR?

При перевозке товара по Европе нужно оформлять международную накладную CMR. В ней содержится информация о продавце, покупателе груза, виде товара, его весе и объеме.

Накладная заполняется отправителем груза, то есть продавцом. Инструкции и указания должна предоставить компания-перевозчик. За достоверность заполнения CRM продавец и перевозчик несут солидарную ответственность.

Что такое франко-перевозчик?

Термин «франко-перевозчик» в толковании Инкотермс 2010 означает доставку продавцом товара, прошедшего таможенную очистку, до франко-места и его передачу перевозчику, нанятому покупателем. В контракте данное понятие употребляется с указанием точного адреса загрузки товара.

Допустим, завод-производитель ООО «Элитный паркет» заключил контракт с покупателем из США. В условиях поставки место «франко-перевозчика» указывается так: «Пунктом передачи является склад ООО «Элитный паркет» по адресу: д. 10, стр. 3, ул. Сыромятническая Ниж., Москва, Российская Федерация», если это – территория продавца. Но можно указать и терминал в Домодедово, если покупатель определил по условиям fca эту территорию для передачи груза перевозчику. Тогда нужно оформить следующим образом: «Пунктом передачи является грузовой терминал аэропорта Домодедово по адресу: с. 7/1, Домодедово аэропорт, Московская обл., Российская Федерация».

Пожалуйста, помогите сделать эту статью лучше.
Ответьте всего на 3 вопроса.

Договор поставки на условиях FCA

Предлагаем вашему вниманию готовый вариант международного договора поставки по условиям FCA. Образец составлен с учетом основных положений терминологии Инкотермс 2010 и в полной мере содержит обязательства и покупателя, и продавца. Если вам нужны консультации по представленному документу, мы готовы вам помочь. Образец контракта можно скачать без регистрации и бесплатно.

Цена на условиях FCA

При подписании двустороннего договора на поставку товара в цену на условиях FCA продавец включает следующие расходы:

Стоимость товара по факту;
Расходы на экспортные пошлины на таможне;
Расходы на доставку груза до места передачи перевозчику.

Когда заключается контракт международной купли-продажи товара, обе стороны внешнеэкономической деятельности должны как можно четче и детальнее прописать условия поставки. Указание свойств товара, обозначение типа транспортного средства, объема груза и другие данные позволят избежать задержек на таможне и дополнительных расходов на экспортные и импортные пошлины и сборы.

Принцип классификации судов РКО (выдержка из правил)

21.06.2017

Принцип классификации судов РКО (выдержка из правил)

ПРИНЦИПЫ КЛАССИФИКАЦИИ СУДОВ РОССИЙСКОГО КЛАССИФИКАЦИОННОГО ОБЩЕСТВА

7.1. Класс судна определяется совокупностью условных символов, присваиваемой судну при его классификации и характеризующей конструктивные особенности судна и условия его эксплуатации в соответствии с правилами исходя из требований безопасности.

7. 2. Классификация судов осуществляется в соответствии с классификацией водных бассейнов.

7.3. Внутренние водные бассейны, включая участки с морским режимом судоходства, классифицируются по разрядам «Л», «Р», «О» и «М» в зависимости от их ветро–волнового режима исходя из следующих условий:

1) в бассейнах разрядов «Л», «Р» и «О» волны 1 %-ной обеспеченности высотой соответственно 0,6, 1,2 и 2,0 м имеют суммарную повторяемость (обеспеченность) не более 4% навигационного времени;

2) в бассейнах разряда «М» волны 3%-ной обеспеченности высотой 3,0 м имеют суммарную повторяемость (обеспеченность) не более 4% навигационного времени.

Участки с морским режимом судоходства начинаются от границы внутренних водных путей. В этих участках могут эксплуатироваться суда всех типов в соответствии с правилами и классом судна. Перечни внутренних водных бассейнов России в зависимости от их разряда, а также морские районы, в которых может осуществляться эксплуатация судов смешанного (река – море) плавания, и условия эксплуатации судов устанавливаются правилами. Морские районы классифицируются по разрядам «О-ПР», «М-ПР» и «М-СП» в зависимости от их ветро-волнового режима и обеспеченности местами убежища.

7.4. Основными символами в формуле класса судов внутреннего плавания являются буквы «Л», «Р», «О» и «М», определяющие конструктивные особенности судна и разряд водного бассейна, в котором оно может эксплуатироваться.

Основными символами в формуле класса судов смешанного (река – море) плавания являются буквенные сочетания «О-ПР», «М-ПР» и «М-СП», определяющие конструктивные особенности судна и условия его эксплуатации в морских районах. Характеристики нормативных высот волн применительно к основному символу класса судна приведены в приложении ¹ 2 к настоящему Положению.

7.5. В зависимости от конструктивных особенностей судна основной символ класса в формуле класса дополняется следующими символами:

1) для судов, построенных под техническим наблюдением Речного Регистра или другой признанной Речным Регистром классификационной организации, — символом ‡, который ставится перед основным символом, например, «‡О»;

2) непосредственно после основного символа класса вносится допускаемая при эксплуатации высота волны в метрах с точностью до первого знака после запятой, например, «‡О1,5».

Для высокоскоростных судов: глиссеров, судов на подводных крыльях (СПК), судов на воздушной подушке (СВП), а также экранопланов ограничения по высоте волны записываются в виде дроби, в числителе которой указывается высота волны при движении судна в водоизмещающем состоянии, а в знаменателе ‑ в эксплуатационном режиме. После дроби указывается тип судна по принципу движения, например, «‡Р1,2/0,8 глиссер», «‡О2,0/1,2 СПК», «‡О2,0/1,5 СВП», «‡Р1,2/0,4 экраноплан»;

3) для судов, имеющих специальные ледовые усиления, после значения высоты волны записываются заключенные в скобки слово «лед» и толщина мелкобитого зимнего льда в сантиметрах, установленная Речным Регистром при согласовании проекта судна, например, «‡О (лед 20)». В формулу класса ледоколов вносится слово «ледокол»;

4) для судов, оборудованных средствами автоматизации в соответствии с правилами, после всех символов, указанных в подпунктах 1 – 3 данного пункта, вносится буква «А», например, «‡О2,0 (лед 20) А»;

5) если судно или его отдельные элементы не в полной мере соответствуют правилам, не проверены практикой эксплуатации, но признаны Речным Регистром годными к эксплуатации как экспериментальные с целью их изучения и проверки, в формулу класса перед символом «‡» вносится символ «Э», например, «Э‡О2,0 (лед 20) А».

При удовлетворительных результатах испытаний, эксплуатации и освидетельствований судна с экспериментальным классом символ «Э» из формулы класса может быть исключен.

7.6. Речной Регистр может исключить или изменить в формуле класса тот или иной символ при изменении или нарушении условий, послуживших основанием введения в формулу класса данного символа.

7.7. Речной Регистр присваивает класс судну при первоначальном освидетельствовании, подтверждает, возобновляет или восстанавливает его при других видах освидетельствований. Присвоение, возобновление или восстановление класса судну удостоверяется выдаваемым на судно классификационным свидетельством.

7.8. Класс судна, эксплуатируемого постоянно в бассейне данного разряда, должен быть не ниже разряда этого бассейна.

7.9. Судно внутреннего плавания, имеющее годное техническое состояние, может быть признано пригодным к эпизо-
дическому плаванию (нерегулярной эксплуатации) в бассейне более высокого разряда при условии выполнения дополнительных требований по конструкции, надводному борту, оборудованию, снабжению, а также ограничений по району плавания, ветро–волновому режиму, сезонности, ледовым условиям и т. п.

7.10. Речной Регистр по заявке судовладельца проводит переклассификацию судов в случае необходимости изменения основного символа класса в формуле класса или типа и назначения судна.

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

ПРИЛОЖЕНИЕ ¹ 1

УКАЗАНИЯ ПО ОПРЕДЕЛЕНИЮ ВМЕСТИМОСТИ

Под вместимостью понимается валовая вместимость судна. Валовая вместимость судов внутреннего плавания GT в регистровых тоннах определяется по формуле:

где V — валовая вместимость, м³, определяемая путем обмера всех помещений судна или подсчитываемая по формуле:

где L и B — длина и ширина судна по конструктивной ватерлинии, м;

H — высота борта, м; T — осадка судна по конструктивную ватерлинию, м; d — коэффициент полноты водоизмещения; a —коэффициент полноты конструктивной ватерлинии; l, b, h — соответственно средние длина, ширина и высота надстроек или рубок, м. В валовую вместимость не включаются объемы рулевой рубки, камбузов, туалетов, всех световых люков и сходных мелких рубок. Валовая вместимость судов смешанного (река – море) плавания определяется в соответствии с правилами обмера судов, содержащимися в Приложении ¹ 1 к Международной конвенции по обмеру судов 1969 года.

ПРИЛОЖЕНИЕ ¹ 2

ХАРАКТЕРИСТИКИ НОРМАТИВНЫХ ВЫСОТ ВОЛН ПРИМЕНИТЕЛЬНО К ОСНОВНОМУ СИМВОЛУ КЛАССА СУДНА

Основной символ класса    «Л»  «Р»   «О»   «М»   «О-ПР»   «М-ПР»   «М-СП»
Нормативная высота волны, м   0,6   1,2     2,0   3,0     2,0     2,5    3,5
Обеспеченность высот волн, %  1   1   1   3   3   3     3

Математика | Бесплатный полнотекстовый | Генерация распределенного ключа на основе R-LWE и дешифрование порога

1. Введение

Появление компьютера в XX веке вызвало бурный рост криптографии, безопасность которой способствовала огромному развитию подключенного общества (например, недавнее криптографические усилия по облегчению реализации модели «умного города» [1]). Точно так же развитие квантовых вычислений и, в частности, алгоритма Шора [2], который делает криптографию, основанную на задачах дискретного логарифмирования и простого факторинга, практически бесполезной против квантового противника, породило новые типы криптографии.

Существует два основных типа криптографии, которые были разработаны для защиты от атак квантовых компьютеров: квантовая и постквантовая криптография. Квантовая криптография опирается на квантовые алгоритмы, которые не могут быть взломаны квантовыми противниками, в то время как постквантовая имеет дело с классическими (неквантовыми) алгоритмами, которые не могут быть взломаны квантовыми противниками. Мы сосредоточимся на постквантовой криптографии, учитывая, что широкое использование умеренно мощных квантовых компьютеров кажется недостижимым в краткосрочной перспективе. В этой области областью, в которой произошли последние достижения, является криптография на основе решетки, о чем свидетельствует тот факт, что в отчете о состоянии второго раунда процесса стандартизации постквантовой криптографии Национального института стандартов и технологий (NIST) [ 3] большинство финалистов третьего раунда представляют собой схемы на основе решетки. В схемах на основе решетки криптография, основанная на проблеме обучения с ошибками (LWE) и ее вариантах, особенно актуальна. Мы будем строить наши предложения вокруг проблемы кольцевого обучения с ошибками (R-LWE).

Существует множество применений постквантовой криптографии, но основное внимание мы уделяем электронному голосованию. Электронное голосование характеризуется значительным недоверием. Отсутствие доверия к другим объектам — это то, что изначально породило концепцию криптографии, поэтому дальнейшее продвижение в этом направлении — следующий логический шаг. Поэтому цель состоит в том, чтобы «распространить» это доверие, чтобы один-единственный коррумпированный игрок больше не мог нарушить протокол. Распределенная криптография — это идея распределения задач между несколькими игроками, так что только определенные их подмножества могут выполнять криптографический протокол. Интерес к распределенной криптографии и, в частности, к постквантовой распределенной криптографии можно увидеть в интересных недавних достижениях в этой области, таких как [4,5].

Добавление постквантовой и распределенной криптографии, наконец, приводит нас к нашей основной теме: генерация распределенного ключа на основе R-LWE и пороговое дешифрование.

1.1. State-of-the-Art

Несмотря на проявленный интерес и потенциальную полезность криптографии с пороговым шифрованием с открытым ключом на основе решетки, количество существующих предложений невелико, особенно предложений, посвященных проблеме R-LWE. Большинство существующих предложений вращаются вокруг проблемы LWE (см., например, [5, 6, 7, 8]), которая имеет потенциальную проблему роста ключей и шифротекстов с O (n2), а не с O (n), как вариант R-LWE (где n — размерность решетки), таким образом, с большей вероятностью потребуется большее количество операций и, следовательно, время вычислений. В мире порогового шифрования на основе R-LWE, насколько нам известно, есть только одно предложение, приведенное в [9].], которая основана на гомоморфных свойствах представленной полностью гомоморфной схемы шифрования. Однако это предложение не включает протокол распределенной генерации ключей (поскольку для этого используется доверенная третья сторона (TTP)). Кроме того, насколько нам известно, ни одно из упомянутых предложений не дает реализации для действительного анализа времени вычислений, даже если реализация постквантовых протоколов является горячей темой, как показано в проекте Open Quantum Safe [10]. Кроме того, проект Open Quantum Safe также показывает нам, что, несмотря на недавние разработки, большинство приложений все еще находятся на стадии прототипа. Краткую информацию о текущем состоянии техники можно найти в таблице 1.

1.2. Вклады

В этой работе мы представляем оригинальные протоколы как распределенной генерации ключей, так и пороговой дешифровки, которые, насколько нам известно, являются первыми пороговыми протоколами на основе R-LWE, включая как дешифрование, так и генерацию ключей. Протоколы основаны на предложении LWE, представленном Бендлином и Дамгардом в [6], чьи идеи перенесены в настройку R-LWE. Кроме того, мы доказываем правильность и безопасность этих протоколов, мы даем набор параметров, для которых наши протоколы имеют более 100 бит безопасности, и мы даем грубую реализацию протоколов на C для анализа их производительности.

1.3. Структура

В разделе 2 мы дадим предварительные сведения, необходимые для работы в области криптографических примитивов, распределенной криптографии и кольцевого обучения с ошибками. В разделе 3 мы представляем протоколы, которые являются основным вкладом в эту работу, в то время как в разделе 4 мы докажем их правильность, а в разделе 5 мы докажем их безопасность. Раздел 6 будет посвящен анализу реализации протоколов на C, и, наконец, в Разделе 7 мы дадим наши окончательные выводы и возможную дальнейшую работу. Для приложений в Приложении A мы приводим доказательства правильности и безопасности против злоумышленника, активно действующего в обоих протоколах, в Приложении B мы приводим доказательства для вспомогательных результатов, а в Приложении C мы даем ссылку на репозиторий, содержащий соответствующий код нашего протокола. выполнение.

Большая часть введения взята из введения в магистерскую диссертацию [11] Феррана Олборха.

2. Предварительные

2.1. Обозначение

Элементы в R, Z или Zq будут обозначаться строчными буквами (a, b, …), а элементы в Rn, Zn или Zqn будут обозначаться жирными строчными буквами (a,b,…) . Мы будем рассматривать Zq с представителями в −q2,q2. Пусть X — случайная величина, X∼χ означает, что X следует распределению вероятностей χ, x⟵χ означает, что x выбирается из случайной величины, следующей за распределением χ, Y⟵χn означает, что Y является вектором таким, что каждая координата независимо выбирается из распределение χ и для любого множества J, j ← $J есть действие равномерного случайного выбора j из J. Мы также будем отождествлять любой многочлен степени n−1, f(x)=a0+a1x+…+an−1xn −1∈Zq[x] с вектором f=(a0,a1,…,an−1)∈Zqn. Говорят, что функция g пренебрежимо мала над n (g:=neg(n)), если ∀k∈Z>0,∃n0∈Z>0 такое, что ∀n≥n0,|g(n)|<1nk. Наконец, говорят, что функция f равна O(g(n)), если существуют M>0 и n0 такие, что |f(n)|≤M·g(n) для всех n>n0, а функция f является называется ω(g(n)), если для всех M>0 существует n0 такое, что |f(n)|>M·g(n) для всех n>n0.

2.2. Криптографические примитивы

Мы начнем с описания некоторых криптографических примитивов, известных определений, протоколов или методов, используемых в криптографии, на основе которых мы будем строить нашу схему и протоколы шифрования. Во-первых, мы формально определим, что такое схема шифрования.

После того, как мы определили криптосистему, нам нужно доказать некоторые ее свойства, чтобы убедиться, что она полезна. Наиболее важными из этих свойств являются правильность и безопасность, и с этого момента мы сосредоточимся исключительно на шифровании с открытым ключом.

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

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

2.3. Распределенная криптография

Конкретная отрасль криптографии, которая нас интересует в этой работе, — это распределенная криптография.

Одной из первых схем обмена секретами и одной из наиболее используемых до сих пор из-за простоты вычислений и понимания является Shamir Secret Sharing. Мы будем активно использовать его на протяжении всей нашей работы.

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

Другими распределенными криптографическими инструментами, которые мы будем использовать, являются методы псевдослучайного совместного использования секрета (PRSS) и неинтерактивного верифицируемого совместного использования секрета (NIVSS). Эти инструменты будут иметь решающее значение в нашем предложении, поскольку безопасность наших протоколов основана на возможности маскировать соответствующую информацию шумом таким образом, чтобы злоумышленник не мог ее получить. Для генерации этого шума мы будем использовать эти два протокола.

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

2.4. Кольцевое обучение с ошибками

Задача обучения с ошибками (LWE) была введена Регевом в 2005 г. в предыдущей версии [15] как обобщение задачи обучения по четности и дала основанный на ней криптографический протокол и сокращение его безопасность к проблеме жесткой решетки (проблема кратчайшего вектора GAP (GAPSVP)).

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

Для решения этих проблем вариант кольцевого обучения с ошибками был представлен Любаевским, Пейкертом и Регевом в [16]. По сути, это частный случай LWE, но в кольцах полиномов над конечными кольцами. Задача над кольцом многочленов Rq=Zq[x]/〈f〉, где f — унитарный многочлен от Zq[x].

Для данного элемента a(x)∈Rq можно увидеть главный идеал, порожденный a(x)

как идеальную решетку в Zqn, которую мы будем обозначать как L(a). Это соответствие легко увидеть в случае f(x)=xn+1 (конкретное Rq мы будем использовать с учетом его конкретных свойств) благодаря тому, что вектор коэффициентов произведения полиномов в Rq можно найти через антициклическая матрица выглядит следующим образом:

где a=(a1,…,an) и b=(b1,…,bn) — коэффициенты при a(x) и b(x) соответственно.

После этого мы можем, наконец, определить проблему кольцевого обучения с ошибками, на которой основана большая часть криптографии на основе решетки.

Таким образом, выборка распределения R-LWE представляет собой точку идеальной решетки, смещенную на запас, заданный распределением χ (которое обычно берется таким образом, чтобы ошибка была небольшой). Поэтому задачу поиска R-LWE можно рассматривать как нахождение точки в идеальной решетке L(a) (помните, что вектор a однозначно определяет идеальную решетку через свою антициклическую матрицу), «близкой» к выборке, и решение R -LWE можно рассматривать как заданную идеальную решетку L(a), решить, все ли заданные точки «близки» к L(a) или распределены равномерно.

При реализации LWE или R-LWE мы будем использовать определенный тип распределения вероятностей по Zq, называемый дискретными гауссианами, учитывая их хорошие свойства и простоту выборки значений из них. Существует несколько различных определений дискретных гауссианов, но в нашей реализации мы будем использовать следующее, так как его гораздо проще выбрать.

Обратите внимание, что если Y ~ Ψσ, то Y = X (mod1), где X ~ N (0, σ), где уменьшение по модулю 1 берет только десятичную часть любого действительного числа.

Заметим, что если Z∼Ψ¯σ, то Z=⌊qY⌉(modq), где Y∼Ψσ.

3. Схема шифрования и протоколы

Проведя все необходимые предварительные приготовления, мы можем, наконец, представить нашу схему шифрования, протокол порогового дешифрования и протокол генерации распределенного ключа, правильность которых мы докажем в разделе 4, безопасность – в разделе 5, проанализируем их реализации в Разделе 6 и дать некоторые последние мысли и возможные будущие работы в Разделе 7.

Мы будем использовать версию схемы шифрования LPR, представленную в [16].

Схема шифрования 1. Пусть q,n,u∈Z>0, где u — количество игроков, а χ — распределение по Rq. Схема шифрования S=(M,C,K,E,D) и генерация ключа, которые мы будем использовать, следующие:

M={0,1}n⊆Zqn≅Rq. Мы будем рассматривать каждый m∈M как элемент в Rq, где m — его вектор коэффициентов.
C⊆Rq×Rq.
Это общедоступная схема шифрования, у нас есть Ks⊆Rq и Kp⊆Rq×Rq.
–
Для любой пары ключей (pk,s)∈Kp×Ks мы будем иметь s⟵∑i=1uχ (что означает сумму u отсчетов χ) и pk=(aE,bE) =(aE,aE·s+e), где aE ←$Rq и e⟵∑i=1uχ.
E={Epk:pk=(aE,bE)∈Kp} такое, что для заданного сообщения m∈M:
где(u,v)=(aE·rE+eu,bE·rE+ ev+m·⌊q2⌋) с rE,eu,ev⟵χ.
D={Ds:s∈Ks} такое, что для заданного зашифрованного текста (u,v)∈C:
, где мы восстановим каждый бит m, округлив каждый коэффициент
до 0 или ⌊q2⌋(modq) а затем сопоставляем 0 с 0 и ⌊q2⌋ с 1.

Теперь мы определим протокол порогового дешифрования на основе этой схемы шифрования и протокол генерации распределенного ключа для совместной работы с ним. Для ясности мы используем TTP для генерации ключей в протоколе шифрования, однако мы ищем полностью распределенную схему, поэтому мы также определяем протокол распределенной генерации ключей, чтобы заменить TTP в протоколе порогового дешифрования. .

См. Таблицу 2.

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

См. Таблицу 3 для более подробного ознакомления с этапами необходимого взаимодействия. Заметим, что субиндексами мы будем обозначать аддитивные вклады, а супериндексами — доли Шамира.

4. Корректность

Имея на руках все предварительные данные и определив оба протокола, мы можем приступить к доказательству их правильности. Мы приведем доказательство для случая пассивного противника на этапе генерации ключа и активного (или пассивного) противника на этапе дешифрования, так как это будет случай, который будет использоваться в нашей реализации, причины такого решения будут объяснены в Раздел 6.1. Доказательство для случая, когда во время протокола генерации ключей присутствует активный противник, будет в Приложении A.1.

В случае, когда мы комбинируем оба протокола, что означает, что мы заменяем TTP в протоколе 1 протоколом 2, выходные данные этого протокола и TTP одинаково генерируются для случая пассивного противника на этапе генерации ключа, как он не может заставить любого игрока отклониться от протокола. Следовательно, мы можем напрямую применить теорему 1. Более того, та же теорема и доказательство верны против пассивного противника, развращающего до t=u−1 игроков, только с учетом того, что у нас будут все расшифровки правильными, поскольку пассивный противник не может сделать никаких ошибок. Игрок отклоняется от протокола.

5. Безопасность

Мы разделим доказательства безопасности протоколов на несколько теорем, чтобы упростить доказательства. Сначала мы докажем CPA-безопасность Схемы шифрования 1 как однопользовательской схемы, а затем докажем, что при распространении протоколов не происходит утечки информации. Наконец, мы добавим все, чтобы доказать безопасность CPA обоих протоколов, используемых вместе.

5.1. Безопасность схемы шифрования

Мы разделим доказательство безопасности схемы шифрования 1 на три отдельные части: сведение безопасности схемы шифрования к проблеме принятия решений R-LWE, сведение проблемы R-LWE с распределением Ψ¯n к проблема R-LWE с усеченным дискретным гауссовым и, наконец, сведение проблемы R-LWE с принятием решений к дискретной гауссовской выборке по K (K-DGS) с полем K, таким что R является его кольцом целых чисел, хорошо известная проблема решетки предполагается трудноразрешимой. Мы проведем это расщепление, потому что первая редукция будет для любого распределения χ, а вторая редукция будет конкретно для распределения Ψ¯n. Первая редукция следует идеям редукции схемы шифрования Регева к LWE, приведенным в [15]. Подробное доказательство см. в Приложении B.

Обратите внимание, что снижение касается семантической безопасности схемы, а не безопасности CPA. Однако хорошо известно, что в шифровании с открытым ключом оба понятия эквивалентны (см., например, теорему 11.1 в [12]).

Во-вторых, мы хотим иметь возможность гарантировать, что, если мы знаем, как решить экземпляр задачи решения R-LWE с усеченной дискретной гауссианой, мы можем решить экземпляр задачи решения R-LWE с распределением Ψ¯n . Это ясно, поэтому, учитывая пример задачи R-LWE решения с распределением Ψ¯n, можно рассматривать его как пример с усеченным дискретным гауссовым распределением, за исключением незначительного количества раз. Следовательно, преимущество противника, решившего оба случая, будет различаться самое большее на ничтожно малую величину, как нам и было нужно.

Наконец, нам нужно увидеть, что наш экземпляр R-LWE так же сложно решить, как задачу решетки, в нашем случае так же сложно решить, как K-DGS, где K — поле, такое что R — его кольцо целых чисел, другими словами, R=OK (подробнее об определении K-DGS см. определение 2.10 и раздел 2.3.3 в [17]). Эта работа уже была проделана в [17], хотя для того, чтобы сделать это должным образом, нам необходимо дать некоторые разъяснения о различных способах определения распределения R-LWE.

Пусть K — числовое поле, R — кольцо целых чисел. Пусть R∨ — дробный кодифференциальный идеал кольца K (R∨={x∈K|Tr(xR)⊂Z}), и пусть TR=KR/R∨. Пусть q≥2 — целочисленный модуль. Давайте распакуем это. Во-первых, в нашем конкретном случае, когда K является круговым полем с n=2k для некоторого k, мы имеем R=Z[x]/〈xn+1〉, поэтому, в свою очередь, можно видеть, что R∨ изоморфен R. Во-вторых, KR=K⊗QR, который изоморфен Rn, поэтому, рассматривая его компонент за компонентом TR, можно рассматривать его как изоморфный Tn с T=R/Z. С этим из пути мы можем видеть их определение.

Теперь наш постулат состоит в том, что это определение, берущее в качестве Ψ n-мерную сферическую непрерывную гауссиану с параметром ξ (распределение, используемое в [17]), а затем снова повышающее ее до Rq, является более общим определением нашего определения 8 используя Ψ¯ξq, в том смысле, что если мы можем решить экземпляр задачи R-LWE, определенной с распределением в определении 8, мы можем решить экземпляр задачи R-LWE с распределением в определении 14. Можно видеть как единое целое, поскольку сферический гауссиан в Rn можно рассматривать как произведение n независимых гауссианов над R с одним и тем же стандартным отклонением. Затем, по сути, то, что мы делаем в определении 14, умножает a на s, затем делит результат на q (что мы можем сделать, поскольку мы видим элементы в KR, которое является полем) и добавляем распределение ошибок. Затем мы уменьшаем его по модулю R∨, попадая в TR. Теперь, если мы рассмотрим его компонент за компонентом, мы, по сути, вычислили a·s/q, а затем добавили к каждому компоненту выборку Ψξq, так что при повышении его снова до Rq∨ (путем умножения на q и округления) мы получаем, что q (a·s/q)=a·s∈Rq∨ и к каждой компоненте добавлена независимая выборка, взятая из Ψ¯ξq. Следовательно, если ρξn — сферический гауссиан с параметром ξ, то для данного противника, решающего R-LWEΨ¯ξq, легко найти противника, решающего R-LWEρξn.

Таким образом, мы можем применить результат из [17], для которого нам нужно дать два быстрых определения решетки.

Наконец, мы можем дать следующий результат.

В заключение мы увидели, что взломать защиту Схемы шифрования 1 не менее сложно, чем решить задачу R-LWE решения с усеченным дискретным гауссианом, что по крайней мере так же сложно, как решить задачу R-LWE решения с помощью распределение Ψ¯n, что, в свою очередь, не менее сложно, чем решение задачи K-DGS.

5.2. Отсутствие утечки информации

В этом разделе нам нужно убедиться, что злоумышленник не получает никакой дополнительной информации, взаимодействуя с распределенным протоколом. Мы начнем сначала с протокола 1, поскольку противник А не может отличить взаимодействие с протоколом от случайных входных данных. Кроме того, мы также дадим противнику возможность выбирать свои доли секретного ключа и ключей PRSS, поскольку это упрощает игру и служит только для того, чтобы убедиться, что безопасность протокола даже выше, чем обычно требуется.

Для этого нам потребуются следующие вспомогательные леммы о статистическом расстоянии, доказательства которых будут в Приложении B. ценности.

Доказательство.

Мы хотим создать атакующую игру, в которой злоумышленник не может отличить протокол, выполненный правильно, или случайные значения, чтобы показать, что при распределении ничего не происходит ни о секретных ключах, ни об ошибках e.

Пусть C обозначает множество коррумпированных игроков, а B — множество честных игроков. Игра «Атака» работает следующим образом. Предположим, что претендент знает секретный ключ s и KH, такие что C⊇H (ключи, которые противник не знает), которые были сгенерированы безопасным образом. Предположим, что претендент посылает противнику A зашифрованный текст (u,v), а затем A представляет (sC′,KHC,dC′) в качестве вызова, где sC′ — доли секретного ключа поврежденных игроков, KHC — ключи KH такие, что C⊉H (ключи, которые знает A), выбранные A, а dC′ — это доли при расшифровке поврежденных игроков. Затем претендент генерирует согласованные доли на s для игроков, не входящих в C.

После того, как все эти предварительные действия выполнены, претендент выбирает b ←${0,1} и действует следующим образом:

Если b=0: Претендент использует протокол дешифрования для вычисления долей дешифрования dB′ для честные игроки. Он вычисляет расшифрованное сообщение m и выводит (дБ’, m).
Если b=1: Претендент вычисляет для каждого H такого, что C⊇H, некоторый элемент rH∈IDn равномерно случайным образом, и мы обозначаем как y многочлен от Rq с вектором коэффициентов ∑C⊉HΦKH(u+v) +∑C⊇HrH. Затем претендент генерирует согласованные доли y+m⌊q2⌋ в дБ’ (претендент знает m, поскольку его можно вычислить с помощью протокола, учитывая, что все необходимое известно) и выводит (дБ′,m).

Наконец, A выводит b˜∈{0,1}, означая, считает ли он, что взаимодействовал с протоколом или с симуляцией, и игра завершается.

Ясно, что m будет правильным в обоих случаях, учитывая доказательство теоремы 1, и, кроме того, y+m⌊q2⌋ будет эффективной «расшифровкой» m в том смысле, что каждый коэффициент будет ближе к 0, если mi=0 и ближе к ⌊q2⌋, если mi=1, потому что

Следовательно, нам нужно только увидеть, что дБ’ неотличимы от того, вычисляются ли они с b=0 или с b=1. , как мы видели при доказательстве теоремы 1, находится в интервале [−2nuκ2+κ, 2nuκ2+κ]n. Следовательно, поскольку распределение каждого коэффициента одинаково и независимо, по лемме 2 имеем 9+m⌊q2⌋ вычислительно неразличимы.

Наконец, складывая все вместе, мы получаем, что выход (дБ’, м) вычислительно неотличим от того, был ли он рассчитан при b=0 или при b=1, поэтому

как мы хотели видеть. □

После теоремы 3 мы увидели, что протокол 1 безопасен только тогда, когда ключи сгенерированы безопасным образом и против пассивного противника, подрывающего t≤u−1 игроков, но стандартно видеть, что тот же протокол безопасен против активного злоумышленник искажает t

Причина этого в том, что мы уже видели, что никакая информация не утекает, поэтому нам нужно только убедиться, что противник не может прервать протокол или вызвать неверный вывод. В случае активного противника (который может заставить игроков произвольно отклоняться от протокола) необходимо, чтобы, если все комбинации t+1 игроков расшифровывали сообщение, должно быть большинство комбинаций t+1 игроков. без коррумпированных игроков. Это дает нам, что t

Теперь нам нужно убедиться, что Протокол 2 не пропускает информацию о том, что противник искажает до t=u−1 игроков. Чтобы сделать это, мы еще раз увидим, что злоумышленник не может отличить взаимодействие с протоколом от симуляции, когда претендент заранее устанавливает значения ключей.

Доказательство.

Мы хотим построить атакующую игру, в которой противник не может отличить правильно выполненный протокол от симуляции, в которой претендент заранее устанавливает значения s, e, aE и KH для всех H.

Пусть C обозначает множество коррумпированных игроков, а B — множество честных игроков. Игра «Атака» работает следующим образом. Предположим, что всякий раз, когда коррумпированному игроку нужно выбрать однородное распределение, он отправляет претенденту запрос на получение случайного значения от случайного оракула. Пусть CC=Commit(s˚C,e˚C,KNHCs,KNHCe,KHC′,aEC′) вызов, выводимый A, первый шаг взаимодействия в протоколе 2, как мы можем видеть в таблице 3. Тогда претендент выбирает b ←${0,1} и действует следующим образом:

Если b=0: Претендент и противник следуют Протоколу 2, чтобы сгенерировать aE,bE и разделить sB’,eB’,KHB,aEB и выходные данные (aE,bE,sB’,eB’,KHB,aEB).
Если b=1: Претендент выбирает s,e∼∑uχ, aE ←$Rq и каждый KH ←$Zq и вычисляет bE=aE·s+e. Затем он использует лазейку в схеме фиксации для восстановления (s˚C,e˚C,KNHCs,KNHCe,KHC′,aEC′) и действует следующим образом. Мы разделим объяснение в зависимости от того, что он моделирует для облегчения понимания, но все будет делаться одновременно, следуя потоку информации, показанному в таблице 3.
—
Для «генерации» s претендент будет использовать ключи KNHCs (все они ему известны, учитывая, что они были сгенерированы с помощью запросов к случайному оракулу через претендента) для восстановления sC, вклад коррумпированных игроков в с. С помощью этой информации претендент может вычислить sB вклад честных игроков в s так, что s=sC+sB. Вычислив эти значения, претендент следует протоколу.
—
Для «генерации» e претендент действует так же, как и для генерации s.
—
Для «генерации» KH претендент выбирает случайные значения в Zq для KHB′ (первый шаг) и фиксирует их. Затем он получит KHC от противника (доли KH, относящиеся к коррумпированным игрокам) и вычислит согласованные доли Shamir KHB, чтобы игроки разделили KH. Затем, как и в протоколе, претендент рассылает доли KHB всем игрокам, не входящим в H.
—
Для «генерации» aE претендент выбирает случайные значения в Rq для aEB (первый шаг) и фиксирует их. Затем он получит aEC (доли aE, относящиеся к коррумпированным игрокам) и вычислит согласованные доли Shamir aEB, чтобы игроки разделили aE. Затем, как и в протоколе, претендент рассылает доли aEB всем игрокам.
—
Для «генерации» bE претендент выводит bE в конце протокола.
Затем претендент выводит (aE,bE,sB′,eB′,KHB,aEB).

Понятно, что поток информации одинаков в обоих случаях и что значения будут как правильными, так и тем, что претендент выбрал заранее, поэтому нам просто нужно убедиться, что противник не может различить значения, полученные при b=0 от полученных при b=1. Для s (и e) ясно, что они неразличимы, так как мы использовали лазейку в схеме фиксации, чтобы установить значения, необходимые до отправки каких-либо сообщений от противника к претенденту. Более того, мы знаем, что никакой утечки информации в NIVSS не было, так как из-за лемм 2 и 3 мы знаем, что никакой утечки информации не было, как при доказательстве теоремы 3.

Для KH (и, в свою очередь, aE, так как они аналогичны) нужно убедиться, что противник не может отличить от KHB′, сгенерированных протоколом, или от случайных в Zq. Чтобы убедиться в этом, мы воспользуемся безопасностью обмена секретами Шамира, поскольку противник может контролировать не более t игроков. Таким образом, общая стоимость полностью не определяется долями коррумпированных игроков, поэтому оба случая (b=0 и b=1) неразличимы для противника.

Наконец, суммируя все, мы получаем, что (aE,bE,sB′,eB′,KHB,aEB) неразличимы, имеем ли мы b=0 или b=1, поэтому

как мы хотели видеть. □

Как и в разделе 4, мы также доказали эквивалент этой последней теоремы для активного противника, однако мы не будем использовать результат для реализации по причинам, которые мы изложим в разделе 6.1. Доказательство можно найти в Приложении A.2.

Доказав безопасность каждого протокола в отдельности, нам нужно только увидеть, что использование обоих протоколов вместе дает нам схему шифрования, которая семантически безопасна.

6. Реализация

Первым шагом для реализации является поиск хороших параметров, гарантирующих безопасность конкретного экземпляра проблемы R-LWE. Чтобы проверить это, мы воспользуемся ограничениями на ξ в лемме 1 и оценкой твердости LWE, данной Albrecht et al. в [19]. Мы используем оценщик LWE, потому что, насколько нам известно, не известно ни о каких серьезных атаках, использующих определенные свойства R-LWE, поэтому расчетная сложность для LWE переводится как расчетная сложность для R-LWE.

6.1. Выбор параметров

Устанавливаем параметр безопасности λ=100. Нам нужно найти следующие параметры: n, q, κ и ξ, которые затем позволят нам вычислить ID и IKG. Сначала мы оставим все в зависимости от n и q, а затем воспользуемся конкретной сложностью экземпляра задачи R-LWE, чтобы исправить n и q.

Пусть n=2β и q∈Z>0. Используя условия на ID из теоремы 1, получаем, что

Для нахождения ξ воспользуемся следующей леммой, доказательство которой находится в Приложении B.

Используя оценку по определению 13 и лемму 4, можно получить следующую оценку:

что при выделении ξ дает нам следующую оценку:

Отсюда мы возьмем равенство, так как при фиксированном q чем больше стандартное отклонение, тем больше сложность этого конкретного случая решения проблемы R-LWE.

Теперь мы можем найти n и q, используя оценщик твердости LWE, который при заданных n,q,α выводит конкретную твердость этого конкретного экземпляра. Мы зададим n как степень двойки, поскольку это позволяет нам использовать более эффективные алгоритмы умножения, а q — как простое число, близкое к степени двойки. Используя это, мы реализовали алгоритм Python для нахождения этих параметров. Код можно найти в репозитории в Приложении C. Это дало следующие результаты в качестве параметров для u=7 и t=2 и более 100 бит безопасности, как видно из таблицы 4.

В этом коде также выполняется вычисление параметров для случая активного противника на этапе генерации ключа с использованием условий теоремы A1. п = 8192. Это, как мы увидим из результатов в разделе 6.3, подрывает жизнеспособность протоколов, поэтому мы считаем наше основное предложение безопасным от злоумышленника, который действует пассивно на этапе генерации ключа и активно на этапе дешифрования.

6.

2. Подробности реализации

Мы приняли несколько решений по внедрению, которые необходимо обсудить. Во-первых, мы закодировали не действительно интерактивный протокол между u разными игроками, а скорее симуляцию, в которой один процессор вычисляет все шаги, имитирующие взаимодействие, в том смысле, что протоколы разделены по шагам между фазами связи, где все вычисления могут быть выполнены без необходимость взаимодействия с другими объектами. Затем программа вычисляет, сколько времени стоит каждый шаг для каждого игрока, и выбирает максимальное значение в качестве «официального» времени для этого шага. Поскольку мы хотим только приблизительно проанализировать, насколько жизнеспособны наши протоколы, это приблизительное значение работает для нас. Это приближение также означает, что выполнение симуляции длится значительно дольше, чем «реальное время» выполнения, что ограничивает нас количеством игроков, которых мы можем разумно использовать.

Во-вторых, чтобы получить наиболее компактную форму совместного использования секрета Шамира, мы использовали Шамир над полем Zq вместо того, чтобы встраивать его в Q. Это основная причина, по которой мы взяли q простым, так как ни одно из сокращений не требует этого. .

В-третьих, что касается реализации PRF, мы использовали основной результат из [20], в котором говорится, что код аутентификации сообщений на основе хэшей (HMAC) является PRF при условии, что основная функция сжатия является PRF. Чтобы обеспечить выполнение этого условия, мы использовали HMAC, основанный на SHA-3.

Наконец, что касается схемы фиксации, которую мы использовали для протокола генерации ключей, мы использовали хэш сообщения, которое мы хотим отправить, объединенным со случайной строкой. Мы использовали SHA-2, потому что, насколько нам известно, он достаточно безопасен. Однако в случае необходимости его можно заменить на более безопасный вариант. Кроме того, нам нужно было использовать схему обязательств только после первого раунда, когда каждый игрок устанавливает свои значения. Это связано с тем, что как только все значения установлены и все доли отправлены, вклады противника больше не нужны, поскольку честные игроки уже могут генерировать большинство правильных значений. А учитывая, что не нужно устанавливать никакое другое значение, которое злоумышленник не может использовать (поскольку противник становится неактуальным), схема обязательств на любом последующем этапе коммуникации кажется ненужной. Тем не менее, эти этапы фиксации могут быть добавлены без каких-либо существенных изменений в протоколе или подтверждения безопасности или правильности, только с немного более медленным выполнением.

6.3. Результаты моделирования

В этом заключительном разделе мы обсудим результаты, полученные нами в результате выполнения кода для моделирования обоих протоколов. Вы можете найти код в репозитории, указанном в Приложении C. Спецификации системы, в которой мы выполнили программы, приведены в Таблице 5. Кроме того, мы использовали следующие библиотеки C: FLINT (Fast Library for Number Theory) для облегчения вычисления в Rq, который, в свою очередь, использует библиотеки GMP и MPFR для работы с числами с множественной точностью и библиотеку OpenSSL для функций, связанных с криптографией, таких как хэши или HMAC. Также стоит упомянуть, что любой результат, который мы получаем от выполнения моделирования, был получен путем усреднения времени 10 000 выполнений кода, чтобы лучше отобразить результаты, избавившись от выбросов.

Из того, что мы видели к этому моменту, есть две основные зависимости: рост времени по отношению к порогу t и рост времени по отношению к размерности решетки. Это так, потому что порог определяет минимально необходимое количество игроков (и наоборот, учитывая количество игроков, мы можем получить максимально допустимый порог), в зависимости от того, защищаемся ли мы от активного или пассивного противника. Как мы видели в разделе 6.1, для модели злоумышленника при заданном n мы можем найти остальные параметры, которые делают протокол безопасным (принимая во внимание, что существует минимальное n, для которого этот анализ работает).

Что касается зависимости от t, анализ протоколов теоретически позволяет увидеть, что при выполнении либо PRSS, либо NIVSS имеется ut разных ключей KH, а это означает, что количество сложений асимптотически растет со значением ut. Это означает, что зависимость должна быть приблизительно экспоненциальной в активном случае, когда u=3t+1, и приблизительно линейной в пассивном случае, когда u=t+1. При получении результатов моделирования мы собрали результаты для значений t, наиболее часто используемых в реальных приложениях, таких как электронное голосование, что означает t<3 для активных противников и t<7 для пассивных противников. Это решение в основном связано с тем, как мы реализовали симуляцию, поскольку вместо того, чтобы протоколы нескольких игроков выполнялись одновременно, мы выполняем их последовательно, а затем берем максимальное затраченное время как общее время. В случае с генерацией ключей, поскольку существуют различные этапы взаимодействия, этот процесс применяется к каждому из них. Поэтому из-за нехватки времени мы были ограничены в том, сколько игроков мы могли симулировать в протоколах при запуске 10 000 запусков кодов. Сказав все это, результаты, которые мы получили для зависимости от t, соответствовали нашим предсказаниям. В активном случае они вели себя более чем линейно в трех имевшихся у нас точках, а в пассивном — примерно линейно. Более глубокий анализ невозможен без сбора более обширных данных.

Что касается зависимости от n, то при наличии умножения полиномов в обоих протоколах, которое реализовано с помощью алгоритма Карацубы, масштабируемого порядка nlog2(3)>n1,5, время асимптотически растет с этим значением . Результаты, полученные для зависимости от n, которые можно увидеть на рисунке 1, показывают ожидаемые результаты только на этапе дешифрования против пассивного противника. Для других случаев мы видим линейное или практически линейное поведение для диапазона значений n, которые нас интересуют для реальных приложений. Это связано с тем, что протоколы должны выполнять гораздо большее количество дополнений, чем продуктов, и эта разница оказывается достаточно высокой, чтобы линейный рост добавления компенсировал рост продукта при этих значениях n.

Наконец, мы хотим обсудить жизнеспособность протоколов. Как видно из Таблицы 6, время генерации ключа значительно меньше, чем время расшифровки, в 4-7 раз медленнее. Это, однако, не представляет большой проблемы, так как по замыслу в большинстве реализаций один этап генерации ключа будет использоваться для расшифровки многих сообщений; поэтому мы можем сосредоточить наш основной анализ на времени расшифровки. На этом фронте 530,36 мс на дешифрование в активном случае переводятся примерно в 7000 сообщений в час, а 131,73 мс на сообщение в пассивном случае переводятся примерно в 27000 сообщений в час. Как мы видим, это будет половина этих голосов в час при n=819.2, которые понадобятся против активного противника, как мы сказали в разделе 6.1.

7. Выводы и будущая работа

В заключение мы хотели бы обобщить ограничения, которые имеет эта работа, и то, как ее можно улучшить в будущих работах, а также дать некоторое представление о некоторых возможных других применениях за пределами изложенные выше.

С точки зрения конструкции наше предложение имеет два основных ограничивающих фактора: во-первых, тот факт, что мы вычисляем шумы утопления с помощью методов PRSS и NIVSS, означает, что время вычислений будет увеличиваться асимптотически экспоненциально с количеством игроков в активном противнике. , что нежелательно. Если бы для неинтерактивного совместного использования значения шума использовались другие методы, этого можно было бы избежать. Во-вторых, и это более характерно для структуры наших протоколов, это тот факт, что использование заглушения шума само по себе приводит к тому, что наша реализация использует очень большие размеры для решеток. Это связано с тем, что для гарантии статистической неразличимости нам нужно, чтобы шум был экспоненциально больше, чем секрет, в то время как схема шифрования LPR требует, чтобы шум был меньше, чем q4, а это означает, что параметр ξ пропорционально очень мал по сравнению с модулем q . Затем это влияет на размер решетки, необходимой для обеспечения того, чтобы конкретный экземпляр проблемы R-LWE имел желаемое количество битов безопасности. Этого ограничения можно было бы избежать, только используя способ обеспечения безопасности, отличный от шумового утопления, что является ключевым элементом нашего предложения.

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

Наконец, мы также хотели бы отметить тот факт, что даже если представленные протоколы были задуманы с идеей их совместного использования, их доказательства безопасности независимы, и поэтому их можно использовать по отдельности. Это означает, что в случае, когда TTP можно доверить генерацию ключа, можно использовать только протокол расшифровки, а затем сделать процесс полностью неинтерактивным. Кроме того, несмотря на то, что протокол генерации ключей в большей степени адаптирован к потребностям схемы шифрования, было бы несложно выделить основные принципы генерации различных типов элементов, поэтому его легко обобщить с помощью аналогичного доказательства безопасности. Это открывает доступ к совершенно новому набору возможностей для приложений.

Вклад авторов

Концептуализация, Р.М. и П.М.; методика, Р.М. и П.М.; программное обеспечение, FA и RM; валидация, Ф.А.; формальный анализ, Ф.А., Р.М. и П.М.; расследование, Ф.А., Р.М. и П.М.; ресурсы, Ф.А., Р.М. и П.М.; написание — подготовка первоначального проекта, F.A.; написание — обзор и редактирование, Ф.А., Р.М. и П.М.; надзор, П.М.; администрирование проекта, Ф.А., Р.М. и П.М.; приобретение финансирования, P.M. Все авторы прочитали и согласились с опубликованной версией рукописи.

Финансирование

Это исследование было частично профинансировано проектом PROMETHEUS Европейского Союза (Программа исследований и инноваций Horizon 2020, грант 780701) и Министерством экономики и конкурентоспособности Испании в рамках проекта MTM2016-77213-R.

Заявление Институционального контрольного совета

Неприменимо.

Заявление об информированном согласии

Неприменимо.

Заявление о доступности данных

Неприменимо.

Конфликт интересов

Авторы заявляют об отсутствии конфликта интересов.

Сокращения

В данной рукописи используются следующие сокращения:

9=e·rE+ev−s·eu.

Поскольку произведение в Rq выполняется через антициклическую матрицу, мы знаем, что

Теперь у нас все еще есть rE,ev,eu∼χ, но для t вкладов мы можем только гарантировать, что они находятся в 2·IKG, так что мы получаем, что

Кроме того, учитывая, что имеется ut ключей KH, мы знаем, что

Складывая оба результата, мы получаем, что

как мы хотели видеть.

Наконец, нам просто нужно увидеть, что когда клиент реконструирует, действительно есть большинство правильных результатов, и это напрямую вытекает из наличия не более t испорченных игроков; следовательно, будет большинство подмножеств t+1 игроков, где все они честны и, таким образом, выводят правильную расшифровку. □

Как и в разделе 4, то же доказательство работает против пассивного противника, развращающего до t=u−1 игроков.

Однако в случае работы с активным противником на этапе генерации ключа, чтобы иметь действительно правильную схему, мы должны видеть, что протокол не может быть остановлен никакими действиями злоумышленника. Однако в протоколе всякий раз, когда проверка не проходит, протокол останавливается. Чтобы справиться с этим, мы реализуем следующую политику разрешения споров, когда спор возникает всякий раз, когда игрок получает значение, которое не проходит проверку, с указанием того, какой другой игрок отправил значения.

Политика работает следующим образом, после остановки протокола игроки просматривают возникшие споры, а затем «устраняют» всех причастных к ним игроков, в том смысле, что новое выполнение протокола генерации ключей начнется без обоих игроков, участвующих в каждом споре, а в случае, если игрок участвует более чем в одном споре, будет проанализирован только первый. Эта политика гарантирует, что протокол будет давать правильный вывод с не более чем t остановок, поскольку между честными игроками не может возникнуть спор, и учитывая, что безопасность схемы основана только на предположении, что существует по крайней мере один вклад в s и e после распределения вывод не вызывает проблем. Наконец, обратите внимание, что, поскольку в каждом споре участвует не более одного честного игрока, доля коррумпированных игроков никогда не превысит u3.

Приложение А.2. Безопасность

Чтобы иметь возможность доказать безопасность, когда генерация ключей направлена против активного противника, нам нужно только переформулировать теорему следующим образом.

Доказательство аналогично доказательству теоремы 1.

Теперь мы докажем, что генерация ключей не дает утечки информации при воздействии на активного противника, подкупающего до t

Доказательство.

Если b=0: Претендент и противник следуют протоколу 2 для генерации aE,bE и долей sB′,eB′,KHB,aEB и выходов (aE,bE,sB′,eB′,KHB,aEB ).
Если b=1: Претендент выбирает s,e∼∑uχ, aE ←$Rq и каждый KH ←$Zq и вычисляет bE=aE·s+e. Затем он использует лазейку в схеме фиксации для восстановления (s˚C,e˚C,KNHCs,KNHCe,KHC′,aEC′) и действует следующим образом. Мы разделим объяснение в зависимости от того, что он моделирует для облегчения понимания, но все будет делаться одновременно, следуя потоку информации, показанному в таблице 3.
- Для «генерации» s претендент будет использовать ключи KNHCs (все они ему известны, поскольку он/она контролирует более t игроков), чтобы восстановить sC, вклад коррумпированных игроков в s . С помощью этой информации претендент может вычислить sB вклад честных игроков в s так, что s=sC+sB. Вычислив эти значения, претендент приступает к протоколу.
- Для «генерации» e претендент действует так же, как и для генерации s′.
- Для «поколения» KH претендент восстанавливает KHC (поскольку он контролирует более t игроков) вклад коррумпированных игроков в KH. С помощью этой информации претендент может вычислить KHB вклад честных игроков таким образом, что KH=KHC+KHB для всех H. Вычислив эти значения, претендент приступает к выполнению протокола.
- Для «генерации» aE претендент восстанавливает aEC (поскольку он контролирует более t игроков) вклад коррумпированных игроков в aE. С помощью этой информации претендент может вычислить aEB вклад честных игроков таким образом, что aE=aEC+aEB. Вычислив эти значения, претендент приступает к протоколу.
- Для «генерации» bE претендент выводит bE в конце протокола.
Затем претендент выводит (aE,bE,sB′,eB′,KHB,aEB).

Понятно, что поток информации одинаков в обоих случаях и что значения будут правильными и теми, что претендент выбрал заранее, поэтому нам просто нужно убедиться, что противник не может различить значения, полученные при b=0 от полученных при b=1. Мы можем видеть, что они неразличимы, поскольку претендент использует лазейку в схеме фиксации, чтобы получить значения, необходимые до того, как любое сообщение будет отправлено от претендента противнику. Более того, опять же, мы знаем, что никакой утечки информации в НИВСС не было по тем же рассуждениям из доказательства теоремы 4.

Следовательно, (aE,bE,sB′,eB′,KHB,aEB) неразличимы для противника независимо от того, были ли они вычислены с b=0 или b=1, поэтому

как мы хотели видеть. □

Доказав безопасность каждого протокола в отдельности, нам нужно только увидеть, что совместное использование обоих протоколов по-прежнему дает нам схему шифрования, которая семантически безопасна.

Приложение Б. Доказательства вспомогательных теорем и лемм

Приложение Б.1. Доказательство теоремы 2

Доказательство.

Что мы хотим увидеть, так это то, что при наличии эффективного противника A, который имеет существенное семантическое преимущество в безопасности, мы можем создать эффективного противника B с доступом к A, который, учитывая экземпляр проблемы R-LWE с принятием решений, может решить это с вероятностью, незначительно превышающей 12.

Пусть (a¯i,b¯i)∈Rq×Rq — пример решения R-LWE задачи. Что нам нужно, чтобы сделать B, так это вывести, является ли полиномиальное количество экземпляров образцами распределения As, χ или равномерного распределения по Rq × Rq, другими словами, мы хотим знать, является ли b¯i=a¯i· s¯+e¯ для некоторых s¯∈Rq и e¯⟵χ.

Обратите внимание, что любой противник A, нарушающий семантическую безопасность, может относиться к одному из двух типов. Либо A имеет существенное семантическое преимущество в безопасности по сравнению со схемой шифрования, когда (aE,bE) генерируются независимо равномерно случайным образом (вместо того, чтобы bE=aE·s+e), либо нет. Для этих случаев мы построим двух разных противников.

Сначала предположим, что A имеет незначительное семантическое преимущество в безопасности по сравнению со схемой шифрования, когда (aE,bE) генерируются независимо равномерно случайным образом. Пусть (a1,b1) — пример задачи R-LWEχ, тогда определим следующую атакующую игру.

Тогда B будет работать следующим образом. Получив экземпляры, он выбирает (a¯1,b¯1) и выполняет атакующую игру 1 с A полиномиальное количество раз. Затем он вычисляет преимущество

Из того, как мы определили противника A, мы знаем, что SSAdv[A,S] нельзя пренебречь, если экземпляры следуют распределению As,χ, тогда SSAdv1∗[A,S] не будет пренебрежимо малым, и если экземпляры однородны по Rq×Rq, тогда SSAdv1∗[A,S] будет пренебрежимо малым. Это означает, что с немалой вероятностью B может решить решающую задачу R-LWEχ так, как мы хотели.

Теперь предположим, что A имеет существенное семантическое преимущество в безопасности по сравнению со схемой шифрования, когда (aE,bE) генерируются независимо равномерно случайным образом. Пусть снова (a1,b1) и (a2,b2) — два случая задачи R-LWEχ, тогда мы определим следующую атакующую игру.

Тогда B будет работать следующим образом. Получив экземпляры, он выбирает два из них (a¯1,b¯1) и (a¯2,b¯2) и выполняет атакующую игру 2 с A полиномиальное количество раз. Затем он вычисляет преимущество

Из того, как мы определили противника A, мы знаем, что, поскольку SSAdv[A,S] нельзя пренебречь, если экземпляры следуют распределению As,χ, тогда SSAdv2∗[A,S] не будет пренебрежимо малым, и если экземпляры равномерны по Rq×Rq, то SSAdv2∗[A,S] будет пренебрежимо малым, так как если b¯i равномерно случайны, то v2 не зависит от открытого ключа и mb22. Это означает, что с непренебрежимо малой вероятностью B может решить проблему принятия решений R-LWEχ так, как мы хотели, поскольку можно с непренебрежимо малой вероятностью отличить незначительное событие от непренебрежимо малого события. □ 9, мы знаем оценку для Ψ¯. Учитывая этот результат, теперь мы можем связать распределения, используя тот факт, что Ω является округленным гауссовым уравнением и неравенством Милля:

Приложение C. Ссылка на репозиторий

Все соответствующие коды для реализации можно найти в следующем репозитории GitHub, последнее обновление сделано 20 декабря 2021 г.: https://github.com/FerranAlborch/Implementation-RLWE-based-distributed-key-generation-and-threshold-decryption.

Ссылки

Сарачевич М.; Адамович, С .; Мачек, Н .; Элхосени, М .; Сархан, С. Модель обмена криптографическими ключами для приложений умного города. ИЭТ Интел. трансп. Сист. 2020 , 14, 1456–1464. [Google Scholar] [CrossRef]
«> Шор П.В. Полиномиальные алгоритмы простой факторизации и дискретного логарифмирования на квантовом компьютере. SIAM Rev. 1999 , 41, 303–332. [Google Scholar] [CrossRef]
Алагич, Г.; Альперин-Шериф, Дж.; Пруд.; Купер, Д.; Данг, К.; Келси, Дж.; Лю, Ю.К.; Миллер, К.; Муди, Д.; Перальта, Р.; и другие. Отчет о состоянии второго раунда процесса стандартизации постквантовой криптографии NIST; Министерство торговли США, NIST: Вашингтон, округ Колумбия, США, 2020 г.
Де Фео, Л.; Мейер, М. Пороговые схемы из предположений об изогении. В материалах Международной конференции IACR по криптографии с открытым ключом, Эдинбург, Великобритания, 4–7 мая 2020 г.; стр. 187–212. [Google Scholar]
Девеви, Дж.; Либерт, Б.; Нгуен, К.; Питерс, Т .; Юнг, М. Неинтерактивные пороговые криптосистемы с защитой CCA2: достижение адаптивной безопасности в стандартной модели без сопряжений. В материалах Международной конференции IACR по криптографии с открытым ключом, виртуальное мероприятие, 10–13 мая 2021 г. ; стр. 659–690. [Google Scholar]
Бендлин, Р.; Дамгард, И. Пороговое дешифрование и доказательства с нулевым разглашением для криптосистем на основе решетки. В материалах конференции по теории криптографии, Цюрих, Швейцария, 9–11 февраля 2010 г.; стр. 201–218. [Google Scholar]
Сингх, К.; Ранган, CP; Банерджи, А. Схема шифрования с открытым ключом на основе идентичности на основе решеток с разделяемым порогом. Междунар. Дж. Вычисл. Мат. 2016 , 93, 289–307. [Google Scholar] [CrossRef]
Boneh, D.; Дженнаро, Р .; Голдфедер, С.; Джайн, А .; Ким, С .; Расмуссен, П.М.; Сахай, А. Пороговые криптосистемы из порогового полностью гомоморфного шифрования. В материалах ежегодной международной конференции по криптологии, Санта-Барбара, Калифорния, США, 19–23 августа 2018 г.; стр. 565–596. [Google Scholar]
Чжан, X.; Сюй, С .; Джин, К.; Се, Р .; Чжао, Дж. Эффективное полностью гомоморфное шифрование от RLWE Ext. Схема порогового шифрования. Будущий генерал. вычисл. Сист. 2014 , 36, 180–186. [Google Scholar] [CrossRef]
Команда разработчиков OQS. Откройте квантовый сейф (OQS). Доступно в Интернете: https://openquantumsafe.org/ (по состоянию на 20 января 2022 г.).
Альборх Эскобар, Ф. Генерация распределенного ключа на основе RLWE и расшифровка порога. Магистерская диссертация, Политехнический университет Каталонии, Барселона, Испания, 2021 г. [Google Scholar]
Боне, Д.; Шоуп, В. Высший курс прикладной криптографии (2020). Черновая версия 0.5 2020 г. Доступна в Интернете: https://toc.cryptobook.us/book.pdf (по состоянию на 10 декабря 2021 г.).
Шамир А. Как поделиться секретом. коммун. ACM 1979 , 22, 612–613. [Google Scholar] [CrossRef]
Крамер Р.; Дамгард, И.; Ишай, Ю. Преобразование общего доступа, псевдослучайный обмен секретами и приложения для защиты вычислений. В материалах конференции по теории криптографии, Кембридж, Массачусетс, США, 10–12 февраля 2005 г.; стр. 342–362. [Академия Google]
Регев О. О решетках, обучении с ошибками, случайных линейных кодах и криптографии. J. ACM (JACM) 2009 , 56, 1–40. [Google Scholar] [CrossRef]
Любашевский В.; Пейкерт, К.; Регев О. Об идеальных решетках и обучении с ошибками над кольцами. J. ACM (JACM) 2013 , 60, 1–35. [Google Scholar] [CrossRef]
Peikert, C.; Регев, О .; Стивенс-Давидовиц, Н. Псевдослучайность Ring-LWE для любого кольца и модуля. В материалах 49-го ежегодного симпозиума ACM SIGACT по теории вычислений, Монреаль, Онтарио, Канада, 19–23 июня 2017 г.; стр. 461–473. [Google Scholar]
Micciancio, D.; Регев, О. Сокращение от наихудшего случая к среднему на основе гауссовых мер. СИАМ Дж. Вычисл. 2007 , 37, 267–302. [Google Scholar] [CrossRef][Зеленая версия]
«> Альбрехт М.Р.; Игрок, Р .; Скотт, С. О конкретной сложности обучения с ошибками. Дж. Матем. Криптол. 2015 , 9, 169–203. [Google Scholar] [CrossRef][Green Version]
Bellare, M. Новые доказательства для NMAC и HMAC: безопасность без сопротивления столкновению. В материалах ежегодной международной конференции по криптологии, Санта-Барбара, Калифорния, США, 17–21 августа 2006 г.; стр. 602–619. [Google Scholar]

Рисунок 1. Время моделирования для n = 256 512 1024 2048 4096 8192.

Таблица 1. Уровень развития.

CPA	Chosen Plaintext Attack
GAPSVP	GAP Shortest Vector Problem
HMAC	Hash-based Message Authentication Code
K-DGS	Discrete Gaussian Sampling over K
LWE	Learning with Errors
NIST	National Institute of Standards and Technology
NIVSS	Non-Interactive Verifiable Secret Sharing
R-LWE	Ring Learning with Errors
PRF	Псевдослучайная функция
PRSS	Псевдослучайный обмен секретами
TTP	Доверенная третья сторона

Предложение	Задача о решетке	Генерация ключей	Реализация
[6]	LWE	✓	✗
[7]	LWE	✗	✗
[8]	LWE	✓	✗
[5]	LWE	✗	✗
[9]	R-LWE	✗	✗
Our proposal	R-LWE	✓	✓

Table 2 Протокол расшифровки.

Таблица 2. Протокол расшифровки.

9039. (j)

Протокол расшифровки
Входы: sj, KH s.t. j∉h, φ · (·), FH
Игрок PJ
	° (U, V)

e˜j=v−sj·u
	→xj+e˜j

Таблица 3. Протокол генерации ключей.

Key Generation Protocol
Inputs: χ, Φ·KG(·), μ
Player Pj
sj,ej←χKHj,KNHjs, KNHje ←$Zq∀\|H\|=n−ts˚j=sj−∑HΦKNHjsKG(μ)e˚j=ej−∑HΦKNHjeKG(μ)aEj ←$RqKHj′,aEj′=Shamir. Shares(KHj,aEj) Cj=Commit(s˚j,e˚j,KNHjs,KNHje,KHj′,aEj′)
	→Cj
	←Ckk=1u
	→s˚j,e˚j,KNHjs,KNHje,KHj′,aEj′
	←s˚k,e˚k,KNHks,KNHke,KHk′,aEk′k=1u
Verify(Ck)j={‘принять’или’отклонить’}k=1u
	→ Verify(Ck)jk=1u
	← Verify(Ci)ki,k=1u
if Verify(Ci)k= ‘отклонить’ для некоторого i,k прерывание
Verify. interval(s˚k)j={‘принять’или’отклонить’}k=1uVerify.interval(e˚k)j={‘принять’или’отклонить’}k=1usj= ∑k=1us˚k+∑H∌PjΦKNHjsKG(μ)·fH(j)ej=∑k=1ue˚k+∑H∌PjΦKNHjeKG(μ)·fH(j)KHj=∑k=1uKHk′aEj=∑k= 1uaEk′
	→Провер.интервал(s˚k)j,Провер.интервал(e˚k)jk=1u
	.interval(e˚i)ki,k=1u
if Verify.interval(s˚i)k= ‘отклонить’ для некоторого i,k прерывание
, если проверить. Interval (Eвку) K = ‘Отказ для I, K ABORT
	→ Aej, KHJTOKS.H∌.H∌P.H∌.H∌PK.H∌P.H∌.H∌P.H∌P.H∌.H∌P.H∌.H∌PK.HJT.HJS.H∌.H∌.HJTOKS.	. ,KHks.t.H∌Pjk=1u
KH=Reconstruct.Shamir(KHk)s.t.H∌PjaE=Reconstruct.Shamir(aEk)bEj=aE·sj+ej
	→aE,bEj
	←bEkk=1u
bE=Reconstruct.Shamir(bEk)
	→bE

Таблица 4. Параметры для безопасной реализации.

n	=	4096
q	=	713,623,846,352,979,940,529,142,984,724,747,568,191,373,381
κ	=	168
ξ	=	14. 8978610 875
ID	=	8,403,614,205,785,368,527,542,540,898,258,331,059,093,504
IKG	=	872,305,872,233,851,041,593,123,383,308,976,128
Bits of Security	=	121

Table 5. Технические характеристики системы.

Таблица 5. Технические характеристики системы.

Operating System	Ubuntu 18.04.5 LTS
CPU	Intel® Core™ i5-8500
Memory	15. 4 GiB
Word Size	64 bits
Тактовая частота процессора	3,00 ГГц

Таблица 6. Сравнение времени между активным и пассивным противником.

6156565656565656565656565656565656565656565656565615656565656565656569н.0655 539,71 мс

n	Key Generation		Decryption		Encryption
n	Active	Passive	Active	Passive	Encryption
4096	7031. 34 ms	1005.63 ms	530.36 ms	131,73 мс	191,79 мс
8192	14320,01 MS	2160,05 MS	967.24S

Примечание издателя: MDPI остается нейтральным в отношении юрисдикционных претензий в опубликованных картах и институциональной принадлежности.

© 2022 авторами. Лицензиат MDPI, Базель, Швейцария. Эта статья находится в открытом доступе и распространяется на условиях лицензии Creative Commons Attribution (CC BY) (https://creativecommons.org/licenses/by/4.0/).

Что такое оптимизм? Использование накопительных пакетов для помощи в масштабировании Ethereum

Коротко

Optimism — это решение для масштабирования блокчейна Ethereum.
Он использует оптимистичные сводки для пакетной обработки транзакций, снижая плату за газ.

Ethereum стал второй по величине криптовалютой по рыночной капитализации, во многом благодаря поддержке смарт-контрактов, которые лежат в основе растущей экосистемы децентрализованных приложений (dapps) и платформ децентрализованных финансов (DeFi).

Но у него есть одна проблема: он медленный и дорогой в использовании из-за постоянно высоких комиссий за транзакции. Пока сообщество Эфириума ждет развертывания запланированных обновлений сети, которые решат эти проблемы, появились решения для масштабирования, которые сделают транзакции Эфириума быстрее и дешевле.

Optimism — одно из таких решений для масштабирования.

Что такое оптимизм?

Оптимизм ускоряет транзакции Ethereum и снижает их стоимость, проводя их на другом блокчейне с использованием передовых методов сжатия данных.

Особая изюминка методологии масштабирования Optimism заключается в ее названии: она использует технику, называемую оптимистическими сверлениями, в соответствии с которой несколько транзакций «свертываются» в одну транзакцию, рассчитываются в другой цепочке блоков, а квитанции возвращаются в основную цепочку блоков Ethereum.

👩‍💻 Протокол 👩‍💻
Мы получили массу удовольствия от времени, потраченного на проектирование, создание и эксплуатацию оптимистичного накопительного пакета.
Извлеченные уроки будут обобщены в следующей важной вехе протокола: в том, что мы сейчас называем «OP 1.0».
— Optimism (✨🔴_🔴✨) (@optimismPBC) 31 января 2022 г.

Оптимистичные накопительные пакеты — это тип накопительного пакета, который «оптимистично» предполагает, что все транзакции в агрегированном пакете действительны. Это экономит время, поскольку отдельные транзакции не должны представляться с прямым подтверждением их действительности. У валидаторов в сводке есть неделя, чтобы запросить всю сводку, если они считают, что она содержит мошеннические данные.

Панель инструментов Dune Analytics показывает, что Optimism снижает комиссию за транзакции Ethereum (также известную как плата за газ) в ошеломляющие 129 раз. Он поддерживается платформами DeFi, такими как Synthetix и Uniswap. По данным Dune Analytics, по состоянию на март 2022 года Optimism обеспечивает около 740 миллионов долларов внутрисетевой стоимости по сравнению с чуть более 1 миллиарда долларов в январе.

Optimism был представлен в июне 2019 года, а тестовая сеть была выпущена в октябре 2019 года. Только в январе 2021 года была запущена альфа-основная сеть, и только в октябре 2021 года Optimism запустила версию основной сети Alpha, которая была совместима. с виртуальной машиной Ethereum. Открытая основная сеть запущена в декабре 2021 г.

Как работает Optimism

Optimism — это, по сути, большой список транзакций, который можно только добавить. Все его свернутые блоки хранятся в смарт-контракте Ethereum, называемом канонической цепочкой транзакций.

Если пользователь не отправит свою транзакцию непосредственно в каноническую цепочку транзакций, новые блоки создаются чем-то, называемым секвенсором. Этот секвенсор мгновенно подтверждает действительные транзакции, а затем создает и выполняет блоки на уровне 2 Optimism — блокчейне, который находится поверх блокчейна L1, в данном случае Ethereum.

Эти блоки представляют собой «свертки» — пакеты транзакций Ethereum. Секвенсор еще больше сжимает эти данные, чтобы уменьшить размер транзакции (и, таким образом, сэкономить деньги), а затем отправляет данные транзакции обратно в Ethereum.

Программное обеспечение 2-го уровня Optimism разработано таким образом, чтобы максимально имитировать код Ethereum. Например, он использует ту же виртуальную машину, что и Ethereum, и взимает плату за газ таким же образом (хотя и по более низкой ставке благодаря своему оптимистичному решению по объединению).

Поскольку Ethereum и Optimism очень похожи внутри, вы можете отправить любой актив ERC-20 — криптовалюту, соответствующую общему стандарту токена Ethereum — между двумя сетями.

Что особенного в Оптимизме?

Оптимизм лучше всего понимать как одно из нескольких решений, пытающихся решить проблему раздувания состояния Ethereum. Сеть Ethereum способна взорваться, и до тех пор, пока обновления основного блокчейна не спасут положение, масштабирующие решения, такие как Optimism, позволяют индустрии децентрализованных финансов Ethereum расти и оставаться доступной для тех, кто не может позволить себе высокие комиссии за транзакции.

Протокол — не единственное решение для масштабирования, использующее оптимистичные свертки. Arbitrum и Boba Network также используют эту технику, чтобы помочь пользователям Ethereum сэкономить на комиссиях. Свертки с нулевым разглашением, еще один популярный тип свертывания, используются Loopring, Immutable X и ZKSync.

Как и у Arbitrum, у Optimism нет собственной криптовалюты для оплаты газа. Он использует ETH, как и Arbitrum. Как и Arbitrum, Optimism находится в стадии бета-тестирования и еще не полностью децентрализован.

Как использовать Оптимизм

Чтобы использовать Optimism, вам необходимо внести свои токены ETH или ERC-20 в мост токенов Optimism. Это позволяет вам совершать транзакции на Ethereum через Optimism. Вы можете конвертировать свои токены обратно в сеть Ethereum, когда закончите.

Чтобы внести свои жетоны, вам необходимо внести их через шлюз оптимизма. Вы можете подключиться к шлюзу через кошелек Web3, такой как MetaMask. Депозиты занимают около двадцати минут, и MetaMask указал нам комиссию в размере 18 долларов за перевод 1 ETH.

Компания Optimism сообщила, что для вывода средств потребуется неделя и 52,72 доллара США. Эта задержка является особенностью недельного испытания, заложенного в оптимистическом сведении Optimism.

После того, как вы внесли средства на Optimism, вы можете использовать их в поддерживаемых децентрализованных приложениях. Uniswap, например, позволяет вам торговать через Optimism, чтобы сэкономить на комиссиях. Все, что вам нужно сделать, это выбрать «Оптимизм» в меню сетей; затем вы можете торговать как обычно.

Изображение: Расшифровка

Будущее оптимизма

У Optimism достаточно средств для продолжения своей работы; в марте 2022 года он закрыл раунд финансирования серии B на сумму 150 миллионов долларов, возглавляемый Andreessen Horowitz и Paradigm, в результате чего стартап был оценен в 1,65 миллиарда долларов. Его дорожная карта включает в себя обновления протокола Optimism, такие как защита от сбоев следующего поколения, сегментированные сводки и децентрализованный секвенсор.

Последний важный момент: пока проект находится в стадии бета-тестирования, команда сохраняет определенный контроль над секвенсором — технологией, ответственной за создание блоков на Optimism.

Оптимизм исторически был более централизованным, чем Эфириум, чьи разработчики не имеют возможности, например, приостановить блокчейн или внести в белый список определенных валидаторов.

Однако Optimism сделала большой шаг к децентрализации в апреле 2022 года, запустив DAO под названием Optimism Collective для финансирования общественных благ и управления протоколом. Он также начал раздавать недавно созданные токены OP пользователям Optimism и другим людям, которые могли бы помочь продвинуть DAO — и децентрализованное будущее Optimism — вперед.

Будьте в курсе новостей криптовалюты, получайте ежедневные обновления на свой почтовый ящик.

Ваш адрес электронной почты

Без рубрики – Несколько мыслей о криптографической инженерии

Это пятая часть серии статей о модели случайного оракула. Предыдущие посты смотрите здесь:

Часть 1: Введение
Часть 2: Формализованное ПЗУ, схема и набросок доказательства
Часть 3: Как мы злоупотребляем ПЗУ, чтобы наши доказательства безопасности работали
Часть 4: Еще несколько примеров использования ПЗУ

Около восьми лет назад я решил написать очень неформальную статью о конкретном методе криптографического моделирования, который называется «модель случайного оракула». Это было еще в старые добрые времена 2011 года, когда была более невинная и мягкая эпоха криптографии. Тогда никто не предвидел, что вся наша стандартная криптография окажется пронизанной ошибками; вам не нужно было напоминать, что «крипто означает криптографию». Люди даже использовали Биткойн, чтобы покупать вещи.

Этот первый случайный пост оракула каким-то образом породил три продолжения, каждое из которых нелепее предыдущего. Думаю, в какой-то момент мне стало стыдно за все это — если честно, это довольно глупо — поэтому я как бы забросил его незаконченным. И это стало для меня главным источником сожаления, так как я всегда планировал пятый и последний пост , чтобы закрыть весь этот беспорядок. Это должно было стать лучшим из всех: то, что я хотел написать все это время.

Чтобы дать вам некоторый контекст, позвольте мне кратко напомнить вам, что такое модель случайного оракула и почему вы должны о ней заботиться. (Хотя вам лучше просто прочитать серию.)

Модель случайного оракула — это сумасшедший способ моделирования (обоснования) хеш-функций, в котором мы предполагаем, что это на самом деле случайные функции, и используем это предположение для доказательства того, что о криптографических протоколах доказать гораздо труднее без такого модель. Почти вся «доказуемая» криптография, которую мы используем сегодня, зависит от этой модели, а это означает, что многие из этих доказательств были бы поставлены под сомнение, если бы они были «ложными».

И чтобы подразнить остальную часть этого поста, я процитирую заключительные абзацы части 4, которая заканчивается следующим образом:

Видите ли, мы всегда знали, что эта поездка не будет длиться вечно, мы просто думали, что у нас есть больше времени. К сожалению, конец близок. Подобно воображаемому городу, который Леонардо де Каприо исследовал в скучной части «Начала», модель случайного оракула рушится под тяжестью собственных противоречий.

Как и было обещано, этот пост будет об этом крахе и о том, что он означает для криптографов, специалистов по безопасности и всех нас.

Во-первых, чтобы сделать этот пост немного более самодостаточным, я хотел бы напомнить некоторые основы, которые я рассмотрел ранее в этой серии. Вы можете смело пропустить эту часть, если вы только что оттуда.

В котором мы (очень быстро) напоминаем читателю, что такое хеш-функции, что такое случайные функции и что такое случайный оракул.

Как обсуждалось в первых разделах этой серии, хеш-функции (или алгоритмы хеширования) — это стандартный примитив, который используется во многих областях информатики. Они принимают некоторый ввод, как правило, строку переменной длины, и многократно выводят короткий «дайджест» фиксированной длины. Мы часто обозначаем эти функции следующим образом:

Криптографическое хеширование берет этот базовый шаблон и добавляет некоторые важные безопасность свойства которые нам нужны для криптографических приложений. Наиболее известны такие свойства, как устойчивость к столкновениям, которые необходимы для таких приложений, как цифровые подписи. Но хеш-функции появляются повсюду в криптографии, иногда в неожиданных местах — от шифрования до протоколов с нулевым разглашением — и иногда эти системы требуют более сильных свойств. Иногда это может быть сложно выразить в формальных терминах: например, многие протоколы требуют хэш-функции для получения чрезвычайно «случайного» вывода.*

На заре доказуемой безопасности криптографы поняли, что идеальная хэш-функция будет вести себя как «случайная функция». Этот термин относится к функции, которая равномерно выбирается из набора 91 218 всех возможных 91 219 функций, имеющих соответствующую спецификацию ввода/вывода (домен и диапазон). В идеальном мире ваш протокол мог бы, например, случайным образом выбирать одну из огромного количества возможных функций при настройке, запекать идентификатор этой функции в открытый ключ или что-то в этом роде, и тогда все было бы хорошо. 9{256}}. Простое «запись» идентификатора выбранной вами функции потребует памяти, экспоненциально зависящей от входной длины функции. Поскольку мы хотим, чтобы наши криптографические алгоритмы были эффективными (имея в виду, несколько более формально, что они работают за полиномиальное время), использование случайных функций практически невозможно.

Итак, мы не используем случайные функции для реализации нашего хеширования. В «реальном мире» мы используем странные функции, разработанные бельгийцами или Агентством национальной безопасности, вроде SHA256, SHA3 и Blake2. Эти функции поставляются с невероятно быстрыми и крошечными алгоритмами для их вычисления, большинство из которых занимают несколько десятков строк кода или меньше. Они, конечно, не случайны, но, насколько мы можем судить, выход выглядит как довольно запутанным.

Тем не менее, разработчики протоколов продолжают стремиться к безопасности, которую действительно случайная функция может обеспечить их протоколу. Что если, спросили они, мы попытаемся разделить разницу. Как насчет того, чтобы мы смоделировали наши хеш-функции, используя случайные функции — просто ради написания наших доказательств безопасности — а затем, когда мы перейдем к , реализуем (или «создадим экземпляр») наши протоколы, мы начнем использовать эффективные хэш-функции, такие как SHA3? Естественно, эти доказательства не будут в точности применимы к реальному протоколу в том виде, в котором он был создан, но они все равно могут быть довольно хорошими.

Доказательство, использующее эту парадигму, называется доказательством в модели случайного оракула или ПЗУ. Для полной механики того, как работает ПЗУ, вам придется вернуться и прочитать серию с самого начала. Что вам, , нужно знать прямо сейчас, так это то, что доказательства в этой модели должны каким-то образом обходить тот факт, что вычисление случайной функции занимает экспоненциальное время. Модель справляется с этим просто: вместо того, чтобы давать отдельным участникам протокола описание самой хэш-функции — она слишком велика, чтобы с ней можно было иметь дело — они дают каждой стороне (включая противника) получают доступ к волшебному «оракулу», который может эффективно оценить случайную функцию H и передать им результат.

Это означает, что каждый раз, когда одна из сторон хочет вычислить функцию, она не делает этого сама. Вместо этого они обращаются к третьему лицу, «случайному оракулу», который хранит гигантскую таблицу входных и выходных данных случайных функций. На высоком уровне модель выглядит примерно так:

Поскольку все стороны в системе «разговаривают» с одним и тем же оракулом, все они получают один и тот же результат хеширования, когда просят его хешировать данное сообщение. Это довольно хороший пример того, что происходит с реальной хэш-функцией. Использование внешнего оракула позволяет нам «похоронить» затраты на оценку случайной функции, так что никому больше не нужно тратить экспоненциальное время на ее оценку. Внутри этой искусственной модели мы получаем идеальные хэш-функции без каких-либо проблем.

Это уже кажется довольно смешным…

Совершенно верно!

Однако — я думаю, что есть несколько очень важных вещей, которые вы должны знать о модели случайного оракула, прежде чем списывать ее со счетов как очевидно бессмысленную:

1. Конечно, все знают, что доказательства случайного оракула не являются «настоящими». Большинство добросовестных разработчиков протоколов признают, что доказательство безопасности в модели случайного оракула , а не на самом деле означает, что это будет безопасно «в реальном мире». Другими словами, тот факт, что случайные доказательства модели оракула являются своего рода подделкой, , а не какая-то глубокая тайна, о которой я вам расскажу.

2. И вообще: доказательства ПЗУ обычно считаются полезной эвристикой. Для тех, кто не знаком с этим термином, «эвристика» — это слово, которое взрослые используют, когда собираются обезопасить свои сбережения с помощью криптографии, которую они ничего не могут доказать.

Я шучу! Фактически, случайные доказательства оракула все еще весьма ценны. В основном потому, что они часто помогают нам обнаруживать ошибки в наших схемах. То есть, хотя случайное доказательство оракула не означает безопасности в реальном мире, невозможность написать один обычно является красным флажком для протоколов. Более того, наличие доказательства ПЗУ, как мы надеемся, является индикатором того, что «кишки» протокола в порядке, и что любые возникающие в реальном мире проблемы будут как-то связаны с хэш-функцией.

3. Схемы, проверенные ПЗУ, имеют довольно приличный послужной список на практике. Если бы пруфы ПЗУ каждый день выбрасывали нелепо сломанные схемы, мы бы, наверное, отказались от этой техники. Тем не менее, мы почти каждый день используем криптографию, проверенную (только) в ПЗУ, и в основном она работает нормально.

Это не означает, что ни одна из проверенных ПЗУ схем никогда не была нарушена при создании экземпляра с помощью определенной хэш-функции. Но обычно эти сбои происходят из-за того, что сама хеш-функция явно сломана (как это произошло, когда MD4 и MD5 некоторое время назад сломались). Тем не менее, эти недостатки обычно исправляются простым переключением на лучшую функцию. Более того, исторически сложилось так, что практические атаки чаще происходят из-за очевидных недостатков, таких как обнаружение коллизий хэшей, искажающих схемы подписи, а не из-за какой-то экзотической математической ошибки. Что подводит нас к последнему критическому замечанию…

4. В течение многих лет многие люди верили, что ПЗУ действительно можно сохранить. Эта надежда была вызвана тем фактом, что схемы ПЗУ, как правило, работали довольно хорошо при реализации с сильными хэш-функциями, и поэтому, возможно, все, что нам нужно было сделать, это найти хэш-функцию, которая была бы «достаточно хороша», чтобы сделать доказательства ПЗУ осмысленными. . Некоторые теоретики надеялись, что причудливые методы вроде криптографической обфускации можно будет каким-то образом использовать для создания конкретных алгоритмов хеширования,1218 вел себя достаточно хорошо, чтобы можно было создать (некоторые) доказательства ПЗУ. **

Таково состояние ПЗУ, или, по крайней мере, так оно было до конца 1990-х годов. Мы знали, что эта модель была искусственной, и тем не менее она упорно отказывалась взрываться или давать совершенно бессмысленные результаты.

А потом, в 1998 году, все пошло наперекосяк.

CGH98: «нереализуемая» схема98 Статья STOC Канетти, Гольдрейха и Халеви (далее CGH). Я собираюсь посвятить оставшуюся часть этого (длинного!) поста объяснению сути того, что они обнаружили.

CGH доказала, что на самом деле существуют криптографические схемы, которые могут быть полностью безопасными в модели случайного оракула, но которые — ужасно — становятся катастрофически небезопасными в ту минуту, когда вы создаете экземпляр хэш-функции с любой конкретной функцией .

Это действительно пугающий результат, по крайней мере, с точки зрения доказуемого сообщества безопасности. Одно дело знать в теории , что ваши доказательства могут быть не такими сильными. Совсем другое дело знать, что на практике существуют схемы, которые могут пройти мимо ваших доказательств, как Терминатор, проникший в Сопротивление, а затем взорваться на вас самым серьезным образом.

Прежде чем мы перейдем к подробностям CGH и связанным с ним результатам, несколько предостережений.

Во-первых, CGH во многом является результатом теории . Криптографические «контрпримеры», которые решают эту проблему, обычно не выглядят как настоящие криптосистемы, которые мы будем использовать на практике, хотя более поздние авторы предложили несколько более «реалистичных» вариантов. На самом деле они созданы для того, чтобы делать очень искусственные вещи, которые никогда не сможет сделать ни одна «настоящая» схема. Это может привести к тому, что читатели отклонят их на основании искусственности.

Проблема с этой точкой зрения в том, что взгляды не являются особо научным способом судить о схеме. И «реально выглядящие», и «искусственные» схемы являются, если доказано, что они верны, действительными криптосистемами. Смысл этих конкретных контрпримеров в том, чтобы сделать нарочито искусственных вещей, дабы подчеркнуть проблемы с ПЗУ. Но это не значит, что «реалистично» выглядящие схемы не подойдут.

Еще одно преимущество этих «искусственных» схем заключается в том, что они относительно легко объясняют основные идеи. В качестве дополнительного примечания по этому поводу: вместо того, чтобы объяснять саму CGH, я собираюсь использовать формулировку того же основного результата, который был предложен Маурером, Реннером и Холенштейном (MRH).

Схема подписи

Основная идея контрпримеров в стиле CGH состоит в том, чтобы сконструировать «надуманную» схему, которая надежно хранится в ПЗУ, но полностью разрушается, когда мы «создаем экземпляр» хэш-функции, используя любую конкретную функцию, то есть функцию, которая имеет реальное описание и могут быть эффективно оценены участниками протокола.

Хотя методы CGH могут применяться с большим количеством различных типов криптосистем, в этом объяснении мы собираемся начать наш пример с относительно простого типа системы: схемы цифровой подписи.

Вы, возможно, помните из предыдущих эпизодов этой серии, что обычная схема подписи состоит из трех алгоритмов: генерация ключа , подписание и проверка . Алгоритм генерации ключей выводит открытый и секретный ключи. Подписание использует секретный ключ для подписи сообщения и выводит подпись. Проверка принимает полученную подпись, открытый ключ и сообщение и определяет, является ли подпись действительной : она выводит «Истина», если подпись проверена, и «Ложь» в противном случае.

Традиционно мы требуем, чтобы схемы подписи были (по крайней мере) экзистенциально не поддающимися подделке при атаке выбранного сообщения или UF-CMA. Это означает, что мы рассматриваем эффективного (с полиномиальным временем) злоумышленника, который может запрашивать подписи на выбранных сообщениях, которые создаются «оракулом подписи», содержащим секретный ключ подписи. Мы ожидаем, что безопасная схема состоит в том, что даже при таком доступе ни один злоумышленник не сможет придумать подпись на некоторых новое сообщение о том, что она не просила подписывающего оракула подписать за нее, за исключением незначительной вероятности. ****

Объяснив эти основы, давайте поговорим о том, что мы собираемся с этим делать. Это будет включать в себя несколько шагов:

Шаг 1: Начните с какой-нибудь существующей безопасной схемы подписи. На самом деле не имеет значения, с какой схемы подписи мы начнем, если мы можем предположить, что она безопасна (в соответствии с определением UF-CMA, описанным выше). Эта существующая схема подписи будет использоваться в качестве строительного блока для новой схемы, которую мы хотите построить.*** Мы назовем эту схему S .

Шаг 2: Мы будем использовать существующую схему S в качестве строительного блока для создания «новой» схемы подписи, которую мы назовем . Построение этой новой схемы в основном будет состоять из добавления странных наворотов к алгоритмам исходной схемы S.

Шаг 3: Подробно описав работу , мы утверждаем, что она полностью безопасно в ПЗУ. Поскольку мы начали с (предполагаемой) безопасной схемы подписи 9 S , этот аргумент в основном сводится к тому, чтобы показать, что в модели случайного оракула странные дополнительные функции, которые мы добавили на предыдущем шаге, на самом деле не делают схему пригодной для эксплуатации.

Шаг 4: Наконец, мы продемонстрируем, что полностью сломан, когда вы создаете случайный оракул с любой конкретной хэш-функцией , независимо от того, насколько «безопасной» она выглядит. Короче говоря, мы покажем, что если вы замените случайный оракул реальной хэш-функцией, получится простая атака, которая всегда приводит к успеху в подделке подписей.

Начнем с объяснения того, как это работает.

Построение сломанной схемы

Чтобы построить нашу надуманную схему, мы начнем с существующей защищенной (в смысле UF-CMA) схемы подписи S . Эта схема включает в себя три упомянутых выше алгоритма: генерацию ключа, подпись и проверку.

Нам нужно построить эквивалентные три алгоритма для нашей новой схемы.

Чтобы облегчить жизнь, наша новая схема просто «заимствует» два алгоритма из S без дальнейших изменений . Эти два алгоритма будут алгоритмами генерации ключа и подписи проверки Итак, две трети нашей задачи по разработке новой схемы уже выполнены.

Таким образом, каждый новый элемент, появившийся в , появится в алгоритме подписи . Как и все алгоритмы подписи, этот алгоритм использует секретный ключ подписи и некоторое сообщение, которое нужно подписать. Он выведет подпись.

На самом высоком уровне наш новый алгоритм подписи будет иметь два подварианта, выбранных ветвью, которая зависит от подписываемого входного сообщения. Эти два случая задаются следующим образом:

«Нормальный» случай: для большинства сообщений M алгоритм подписи просто запускает исходный алгоритм подписи из оригинальной (безопасной) схемы S . Это выведет совершенно красивую подпись, которая, как мы можем ожидать, будет работать нормально.

«Злой» случай: для подмножества сообщений (разумного размера), которые имеют другую (и очень специфическую) форму, наш алгоритм подписи не будет выводить подпись. Вместо этого он выводит секретный ключ для всей схемы подписи. Это результат, который криптографы иногда называют «очень, очень плохим».

Пока что это описание скрывает все действительно важные детали, но, по крайней мере, дает нам представление о том, куда мы пытаемся двигаться.

Напомним, что в соответствии с определением UF-CMA, которое я описал выше, злоумышленнику разрешено запрашивать подписи для произвольных сообщений. Когда мы рассматриваем возможность использования этого определения с нашим модифицированным алгоритмом подписи, легко увидеть, что наличие этих двух случаев может сделать вещи захватывающими.

В частности: если какой-либо злоумышленник может создать сообщение, которое запускает «злой» случай, его запрос на подпись сообщения фактически приведет к тому, что он получит секретный ключ схемы . С этого момента она сможет подписать любое сообщение, которое захочет — что, очевидно, нарушает безопасность схемы UF-CMA. Если это слишком теоретически для вас: представьте, что вы запрашиваете подписанный сертификат у LetsEncrypt и вместо этого получаете копию ключей подписи LetsEncrypt. Теперь вы тоже являетесь центром сертификации. Именно такую ситуацию мы описываем.

Единственный способ, которым эта схема могла бы быть доказана в безопасности, это если бы мы могли как-то исключить «злое» дело вообще.

Более конкретно: мы должны показать, что ни один злоумышленник не может создать сообщение, которое запускает «злой случай», или, по крайней мере, что их вероятность появления такого сообщения очень и очень мала (незначительна). Если бы мы могли это доказать, то наша схема в основном сводилась бы к исходной схеме безопасности . Что означает, что наша новая схема будет безопасной.

Короче говоря, мы встроили в нашу новую схему нечто вроде бэкдора «мастер-пароль». Любой, кто знает пароль, может взломать схему. Теперь все зависит от того, сможет ли злоумышленник подобрать этот пароль.

Так что же такое «черный ход»?

Сообщение, нарушающее схему, конечно, вовсе не пароль. Поскольку это компьютерная наука, и нет ничего простого, сообщение на самом деле будет компьютерной программой . Мы назовем это P.

Более конкретно, это будет своего рода программа, которая может быть декодирована в рамках нашего нового алгоритма подписи, а затем оценена (на некоторых входных данных) интерпретатором, который мы также поместим в этот алгоритм.

Если говорить об этом формально, мы бы сказали, что сообщение содержит кодировку программы для универсальной машины Тьюринга (UTM), а также целое число в унарной кодировке t , представляющее количество временных шагов, которые машина должна быть разрешено работать. Тем не менее, я совершенно согласен, если вы предпочитаете думать о сообщении как о фрагменте Javascript, большом двоичном объекте виртуальной машины Ethereum в сочетании с некоторым максимальным значением «газа» для запуска, кодировке . tgz контейнера Docker или любом другом. исполняемый формат, который вам нравится.

Что действительно важно, так это функционирование программы P .

Программа P , которая успешно инициирует «критический случай», содержит эффективную (например, полиномиальную) реализацию хеш-функции. И не просто любая хэш-функция. Чтобы действительно активировать черный ход, алгоритм P должен иметь функцию, идентичную или, по крайней мере, очень похожую на функцию случайного оракула H .

Алгоритм подписи может проверить это сходство несколькими способами. Статья MRH дает очень элегантный вариант, о котором я расскажу ниже. Но для целей этой непосредственной интуиции давайте предположим, что наш алгоритм подписи проверяет это сходство вероятностно . В частности: чтобы убедиться, что P соответствует H, он не будет проверять соответствие при каждом возможном входе. Например, можно просто проверить, что P (x) = H (x) для некоторого большого (но полиномиального) числа случайных входных значений x.

Итак, это черный ход.

Давайте вкратце подумаем о том, что это означает для безопасности как внутри, так и вне режима случайного оракула.

Случай 1: в модели случайного оракула

Напомним, что в модели случайного оракула «хэш-функция» H моделируется как случайная функция . На самом деле ни у кого в протоколе нет копии этой функции, у них просто есть доступ к третьей стороне («случайному оракулу»), которая может оценить ее для них.

Если злоумышленник захочет запустить «злой случай» в нашей схеме подписи, ему каким-то образом нужно будет загрузить описание случайной функции из оракула. затем закодируйте его в программу P и отправьте подписывающему оракулу. Это кажется принципиально сложным.

Чтобы сделать это точно — то есть, чтобы P соответствовало H при каждом вводе — злоумышленник должен запросить у случайного оракула каждый возможный ввод, а затем разработать программу P , которая кодирует все эти результаты. Достаточно сказать, что эта стратегия не будет практичной: для выполнения любого из них потребуется экспоненциальное количество времени, и размер P также будет экспоненциальным по входной длине функции. Таким образом, этот злоумышленник практически гарантированно потерпит неудачу.

Конечно, злоумышленник может попытаться обмануть: создать небольшую функцию P , которая соответствует только H на небольшом количестве входных данных, и надеяться, что подписывающий не заметит. Тем не менее, даже это кажется довольно сложным, чтобы избежать наказания. Например, чтобы выполнить вероятностную проверку, алгоритм подписи может просто проверить, что P (x) = H (x) для большого количества случайных входных точек x. Этот подход позволит поймать мошенника с очень высокой вероятностью.

(В конечном итоге мы воспользуемся чуть более элегантным подходом к проверке функции и обсудим этот момент ниже. )

Вышеизложенное едва ли можно назвать исчерпывающим анализом безопасности. Но на высоком уровне наш аргумент теперь должен быть ясен: в модели случайного оракула схема безопасна, потому что злоумышленник не может знать достаточно короткий «пароль» бэкдора, который взломает схему. Устранив «злой случай», схема просто деградирует к исходной, защищенной схеме S .

Случай 2: В «реальном мире»

В реальном мире мы не используем случайных оракулов. Когда мы хотим реализовать схему, которая имеет доказательство в ПЗУ, мы должны сначала «создать экземпляр» схемы, подставив какую-нибудь реальную хеш-функцию вместо случайного оракула H.

. по определению быть эффективным оценивать и описывать. Это неявно означает, что он обладает описанием полиномиального размера и может быть оценен за ожидаемое полиномиальное время. Если бы мы этого не требовали, наши схемы никогда бы не сработали. Более того, мы должны дополнительно предположить, что все стороны, включая злоумышленника, обладают описанием хеш-функции. Это стандартное предположение в криптографии и просто формулировка принципа Керкхоффа.

С учетом этих фактов проблема с нашей новой схемой подписи становится очевидной.

В этом параметре злоумышленник фактически имеет доступ к короткой эффективной программе P , которая соответствует хеш-функции H . На практике эта функция, вероятно, будет чем-то вроде SHA2 или Blake2. Но даже в странном случае, когда это какая-то сумасшедшая запутанная функция , злоумышленник все равно должен иметь программу, которую он может эффективно оценить. Поскольку у злоумышленника есть эта программа, он может легко закодировать ее в достаточно короткое сообщение и отправить подписывающему оракулу.

Когда алгоритм подписи получит эту программу, он выполнит своего рода тест этой функции P против своей реализации H , и — когда он неизбежно найдет совпадение между двумя функциями с высокой вероятностью — он вывести секретный ключ схемы.

Следовательно, в реальном мире наша схема всегда и навсегда полностью нарушена.

Несколько скучных технических подробностей (которые вы можете пропустить)

Если вас устраивает неточная техническая интуиция, которую я изложил выше, не стесняйтесь пропустить этот раздел. Вы можете перейти к следующей части, которая пытается решить сложные философские вопросы, такие как « что это значит для случайного оракула модели » и « я думаю это все ерунда » и « почему мы ездим по бульвару, а паркуемся на подъездной дорожке? »

Все, что я собираюсь сделать, это уточнить несколько технических деталей.

Одна из самых больших частей, которая отсутствует в приведенной выше интуиции, — это спецификация того, как алгоритм подписи проверяет, что программа P , которую он получает от злоумышленника, действительно «соответствует» функции случайного оракула H. Очевидный способ состоит в том, чтобы просто оценить P( x ) = H( x ) для каждого возможного входа x и вывести секретный ключ схемы, если каждое сравнение будет успешным. Но выполнение этого исчерпывающего требует экспоненциального времени.

В документе MRH предлагается очень изящный альтернативный способ решения этой проблемы. Предлагают протестировать функции на нескольких входных значений , причем даже не случайных. Более конкретно, они предлагают проверить, что P( x ) = H( x ) для значений с особым требованием, чтобы q было целым числом таким, что . Здесь представляет собой длину кодирования программы P в битах, а k — регулируемый параметр защиты схемы (например, k =128).

Это означает, что для запуска бэкдора злоумышленник должен придумать программу P , которая может быть описана некоторым количеством битов (назовем ее n ) и при этом сможет правильно сопоставить выходные данные H с , например, q=2 n +128 различных входных точек. Если мы консервативно предположим, что H производит (как минимум) 1-битный дайджест, это означает, что мы фактически кодируем как минимум 2 n +128 бит данных в строку длиной n .

Если функция H является реальной хеш-функцией, такой как SHA256, то злоумышленнику должно быть достаточно легко найти некоторые n- битовая программа, которая соответствует H , скажем, q = 2 n +128 различных точек. Например, вот реализация SHA256 на Javascript, которая занимает менее 8192 бит. Если мы встроим интерпретатор Javascript в наш алгоритм подписи, то ему просто нужно оценить данную программу на q = 2(8,192)+128 = 16 512 различных входных точек, сравнить каждый результат с его собственной копией SHA256, и если они все совпадает, выведите секретный ключ.

Однако, если H — это случайный оракул, злоумышленнику гораздо сложнее его использовать. Результатом оценки случайного оракула в q различных точек должна быть случайная строка длиной (как минимум) q бит. Тем не менее, для того, чтобы бэкдор сработал, мы требуем, чтобы кодировка программы P была меньше половины размера . Поэтому вы можете представить себе процесс, с помощью которого злоумышленник сжимает случайную строку в эту программу 9.1278 P , чтобы быть очень эффективным алгоритмом сжатия, человек берет случайную строку и сжимает ее в строку меньше половины размера.

Несмотря на то, что вы, возможно, видели в Силиконовой долине ( NSFW ), алгоритмы сжатия не могут с высокой вероятностью сжимать случайные строки так сильно. В самом деле, для данной строки битов это настолько маловероятно, что атакующий преуспевает с вероятностью, которая в лучшем случае пренебрежимо мала в параметре безопасности схемы 9.1218 к . Это эффективно нейтрализует черный ход, когда H является случайным оракулом.

Фух.

Так что же все это значит?

Судя по действиям, а не словам, мнения криптографов мира по этому вопросу во многом разделились.

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

Прикладные академические криптографы с радостью приветствовали новые результаты и быстро написали 10 000 новых статей, каждая из которых нашла какой-то новый способ удалить случайные оракулы из существующей конструкции, в то же время делая указанную конструкцию значительно медленнее. более сложными и/или основанными на совершенно новых выдуманных и надуманных теоретико-числовых предположениях. (Исходя из личного опыта, это было прекрасное время.)

Практикующие продолжал доверять модели случайного оракула. Ведь действительно, , почему не ?

И, если честно, спорить с практиками по этому поводу довольно сложно.

Это потому, что очень разумная точка зрения состоит в том, что эти «контрпримеры» смешны и искусственны. Ладно, я просто хороший. Они полная чушь, если честно. Никто никогда не разработает схему, которая выглядит так нелепо.

В частности, вам нужна схема, которая явно анализирует ввод как программу, запускает эту программу, а затем проверяет, соответствует ли вывод программы другой хеш-функции. Какой протокол реального мира может сделать такую глупость? Разве мы не можем все еще доверять модели случайного оракула для схем, что не являются такими глупыми?

Ну, может быть, а может и нет.

Один простой ответ на этот аргумент состоит в том, что есть примеры менее искусственных схем, которые все же имеют случайные проблемы с оракулом. Но даже если считать эти результаты искусственными — факт остается фактом: пока мы знаем только о случайных контрпримерах оракулов, которые кажутся искусственными, у нас нет принципиального способа доказать, что вредность повлияет только на «искусственно выглядящие» протоколы. На самом деле, понятие «искусственно выглядящий» в значительной степени является человеческим суждением, а не чем-то, что можно реально обдумать математически.

На самом деле, в любой момент кто-то может случайно (или намеренно) предложить совершенно «нормально выглядящую» схему, которая проходит проверку в модели случайного оракула, а затем разлетается на куски, когда ее фактически развертывают со стандартной хеш-функцией. К этому моменту схема может питать нашу инфраструктуру центра сертификации, или Биткойн, или наши системы ядерного оружия (если хотите быть драматичным).0005

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

В конечном счете, это странная и разочаровывающая ситуация, и, честно говоря, я ожидаю, что все закончится плачевно.

Фото пользователя Flickr joyosity.

Примечания:

* Интуитивно это определение очень похоже на «псевдослучайность». Псевдослучайные функции должны быть неотличимы от случайных функций только в условиях, когда злоумышленник не знает какой-то «секретный ключ», используемый для этой функции. В то время как хеш-функции часто используются в протоколах, где нет возможности использовать секретный ключ, например, в протоколах шифрования с открытым ключом.

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

*** Может показаться, что «предположим, что существует схема защищенной подписи» — это дополнительное предположение. Однако: если мы собираемся делать заявления в модели случайного оракула оказывается, что дополнительных допущений нет. Это связано с тем, что в ПЗУ у нас есть доступ к «защищенной» (по крайней мере, устойчивой к коллизиям, устойчивой к [второму] предварительному изображению) хеш-функции, что означает, что мы можем создавать подписи на основе хэшей. Таким образом, в модели случайного оракула существование схем подписи предоставляется «бесплатно».

**** Оговорка «за исключением незначительной вероятности [в регулируемом параметре безопасности схемы]» важна по двум причинам. Во-первых, целеустремленный злоумышленник всегда может попытаться подделать подпись, просто угадывая значения по одному, пока не получит то, что удовлетворяет алгоритму проверки. Если атакующий может бежать неограниченное количество временных шагов, он всегда в конце концов выигрывает эту игру. Вот почему современная теоретико-сложная криптография предполагает, что наши злоумышленники должны работать в течение некоторого разумного периода времени — обычно это количество временных шагов, полиномиальное по параметру безопасности схемы. Однако даже противник с ограниченным полиномиальным временем может попытаться подобрать сигнатуру методом грубой силы. Ее вероятность успеха может быть относительно небольшой, но она отлична от нуля: например, она может добиться успеха после первого предположения. Таким образом, на практике в определениях безопасности, таких как UF-CMA, мы требуем не «ни один злоумышленник никогда не сможет подделать подпись», а скорее «все злоумышленники преуспеют с минимальной вероятностью [в параметре безопасности схемы]», где пренебрежимо мала имеет очень конкретное значение.

Мэтью Гринин, основы, доказуемая безопасность, без категорий 5 января 2020 г. 6 января 2020 г.

Недавно Эдвард Сноуден опубликовал свои мемуары. В некоторых частях Интернета это возродило давние дебаты: а именно, , стоило ли оно того? Утечки Сноудена сделали нас лучше, или Сноуден просто поставил нас в неловкое положение и отбросил безопасность США на десятилетия назад? Большинство аргументов настолько знакомы, что в данный момент они кажутся скучными. Но сколько бы раз я их ни перечитывал, все равно чувствую, что чего-то важного не хватает.

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

Что нам рассказали утечки Сноудена о современных возможностях слежки? И что мы узнали о нашей способности защищаться от них?

И хотя сами утечки немного отошли в прошлое — а мир продолжает усложняться — технические опасения, о которых нас предупредил Сноуден, становятся все более заметными.

Жизнь до июня 2013 года

Трудно поверить, что разоблачения Сноудена начались более шести лет назад. Также легко забыть, как много всего изменилось за прошедшие годы.

Шесть лет назад значительная часть нашего общения осуществлялась открытым текстом. Трудно поверить, насколько все было плохо, но еще в 2013 году Google была одной из немногих крупных технологических компаний, которые по умолчанию развернули HTTPS в своих сервисах, и даже здесь у них были некоторые серьезные исключения. Веб-клиенты были еще хуже. Эти графики (источник и источник) не охватывают весь период времени, но дают некоторую изюминку:

Вне HTTPS ситуация была еще хуже. В 2013 году подавляющее большинство текстовых сообщений было отправлено с помощью незашифрованных SMS/MMS или плохо зашифрованных служб обмена мгновенными сообщениями, что было кошмаром для конфиденциальности. До будущих разработок, таких как включение стандартного сквозного шифрования в WhatsApp, остались годы. Вероятно, единственным (и удивительным) исключением была компания Apple, которая опережала всех в развертывании сквозного шифрования. Это было в значительной степени уравновешено огнем шин, которым был Android в те дни.

Но даже эти необработанные факты не говорят всей истории.

Что сложнее представить на диаграмме, так это то, насколько по-разному относились к слежке до Сноудена. Идея о том, что правительства будут осуществлять крупномасштабный перехват нашего коммуникационного трафика, была точкой зрения, над которой задумывались относительно немногие «нормальные люди» — в основном она ограничивалась списками рассылки безопасности и сценариями X-Files. Конечно, все понимали, что государственная слежка — это вещь, в аннотации. Но на самом деле говоря об этом, вы должны были выглядеть немного глупо, даже в параноидальных кругах.

То, что эти проблемы получили респектабельность , является одной из самых важных вещей, которые Сноуден сделал для нас.

Так что же нам на самом деле сказали утечки Сноудена?

Самое замечательное в утечках Сноудена было то, что он почти ничего нам не рассказал. Он показал нам. Большинство откровений пришло в виде слайдов в Powerpoint, убожество которых каким-то образом делало все это более реальным. И несмотря на всю усталость от откровений, то, что он показал нам, было замечательным. Я собираюсь выделить несколько основных моментов с моей точки зрения. Многие из них связаны с криптографией, просто потому, что об этом этот блог. Другие рассказывают более простую историю о том, насколько уязвимы наши сети.

«Собери все»
До Сноудена даже скептики в области слежки, вероятно, признавали, что да, АНБ собирает данные о конкретных целях. Но даже самые параноидальные наблюдатели были потрясены масштабами того, что на самом деле делало АНБ.
В разоблачениях Сноудена было подробно описано несколько программ, которые были настолько поразительны по широте и масштабу собираемых данных, что единственными реальными ограничениями для них были технические ограничения аппаратного обеспечения АНБ. Большинство из нас знакомы с известными примерами, такими как общенациональный сбор метаданных телефонов. Но именно причудливые, непонятные утечки действительно привлекают внимание. Например:
«Зрительный нерв». С 2008 по 2010 год АНБ и GCHQ собрали миллионы неподвижных изображений со всех сайтов Yahoo! Поток веб-чата Messenger и использовал их для создания огромной базы данных для распознавания лиц. Сбор данных не имел особого смысла или причины — т. е. он не был нацелен на конкретных пользователей, которые могли представлять угрозу национальной безопасности. Это было просто… все. Не верите мне? Вот откуда мы знаем, насколько это было неизбирательно: программа даже не обязательно нацеливалась на лица. Получилось… прочее:
МИСТИК/СОМАЛГЕТ. Помимо сбора большого количества интернет-метаданных, АНБ записало полный звук каждого сотового звонка, сделанного на Багамах. (Примечание: это не просто звонки на Багамы, что может быть своего рода проблемой. Они злоупотребили функцией доступа правоохранительных органов, чтобы записывать все мобильные звонки, сделанные внутри страны.) Излишне говорить, что правительство Багамских островов не участником этой тайны.
МЫШЕЧНЫЙ. Если кто-то считает, что АНБ избежало атак на американских провайдеров, то ряд утечек в 2014 году задокументировал, что АНБ прослушивало внутренние выделенные линии, используемые для соединения дата-центров Google и Yahoo. Это дало агентствам доступ к огромному и, вероятно, неизбирательному доступу к потокам данных о пользователях в США и Европе, информация, вероятно, была выше данных, которыми эти компании уже делились с США в рамках существующих программ, таких как PRISM. Эта утечка, вероятно, наиболее известна благодаря этому слайду:
Yahoo!, пост-Сноуден. И если вы считаете, что все это закончилось после утечки Сноудена, с тех пор мы узнали еще более тревожные вещи. Например, в 2015 году Yahoo была уличена в установке того, что было описано как «руткит», который сканировал каждое электронное письмо в своей базе данных на наличие определенных селекторов по запросу правительства США. Это было настолько вопиющим образом, что компания даже не сообщила об этом директору по информационной безопасности, который ушел на следующей неделе. На самом деле, благодаря Сноудену, мы знаем намного больше о сотрудничестве Yahoo в этот период времени.
Эти примеры не обязательно худшее, что мы узнали из утечек Сноудена. Я выбрал их только для того, чтобы проиллюстрировать, насколько на самом деле было совершенно неизбирательным наблюдение агентства. И не потому, что АНБ было особенно злым, а просто потому, что это было легко сделать. Если у вас были какие-то иллюзии, что эти данные тщательно фильтруются, чтобы исключить сбор данных, принадлежащих гражданам США или американским компаниям, утечка Сноудена должна была вас прояснить.
Включение SIGINT
Утечки информации о Сноудене также помогли разрушить вторую иллюзию: идею о том, что АНБ было на стороне ангелов, когда дело касалось повышения безопасности Интернета. Я много писал об этом в этом блоге (иногда с впечатляющими результатами), но, возможно, об этом нужно сказать еще раз.
Один из самых важных уроков, которые мы извлекли из утечек Сноудена, заключался в том, что АНБ уделяет большое внимание своей миссии по наблюдению, вплоть до того, что оно готово активно внедрять уязвимости в продукты и стандарты шифрования, используемые в сетях США. И такого рода вещи были не просто случайным преступлением возможности — агентство тратило 250 миллионов долларов в год на программу под названием SIGINT Enabling Project. Его целью было, по сути, обойти наше коммерческое шифрование любой ценой.
Такого рода саботаж, разумеется, является чем-то, что даже самые параноидальные исследователи безопасности не могли бы предсказать из наших собственных спецслужб. Агентства, у которых якобы есть миссия по защите сетей США.
Отчеты Сноудена не только выявили существование этих общих программ, но и выявили множество неприятных подробностей, что привело к большому объему последующих расследований.
Например, утечки Сноудена содержали конкретные утверждения об уязвимости в стандарте NIST под названием Dual EC. Возможность такой уязвимости ранее отмечали американские исследователи безопасности Дэн Шумоу и Нильс Фергюсон несколькими годами ранее. Но, несмотря на разумные доводы в пользу перепроектирования этого алгоритма, эти исследователи (и другие) были в основном проигнорированы «серьезными» людьми из NIST.
Документы Сноудена все изменили. Утечки стали сокрушительным смущением для криптографического истеблишмента США и привели к некоторым реальным изменениям. Мало того, что АНБ преднамеренно использовало бэкдор Dual EC, похоже, что они сделали это (и использовали NIST), чтобы развернуть бэкдор в продуктах безопасности США. Более поздние расследования показали, что Dual EC присутствовал в программном обеспечении RSA Security (предположительно из-за секретного контракта с АНБ) и в брандмауэрах, созданных Juniper Networks.
(Чтобы сделать все немного более ужасающим, бэкдор Juniper Dual EC позже был захвачен и обращен против Соединенных Штатов неизвестными хакерами — что наглядно иллюстрирует, насколько все это было безрассудно. )
И, наконец, есть загадок . Слайды Сноудена показывают, что АНБ широко расшифровывало соединения SSL/TLS и IPsec. Даже помимо саботажа типа SIGINT, это поднимает огромные вопросы о , что, черт возьми, здесь происходит на самом деле. Есть теории. Они могут быть правильными, а могут и нет, но, по крайней мере, сейчас люди думают о них. По крайней мере, ясно, что что-то очень и очень не так.

Что-то улучшилось?
Это вопрос на 250 миллионов долларов.
Некоторые индикаторы верхнего уровня на удивление здоровы. Внедрение HTTPS взлетело как ракета, отчасти благодаря готовности Google использовать его в качестве сигнала для ранжирования в поиске, а также появлению бесплатных центров сертификации, таких как LetsEncrypt. Возможно, все это в конечном итоге произошло бы и без Сноудена, но это менее вероятно.
Сквозное шифрование сообщений также получило широкое распространение, в основном благодаря принятию WhatsApp и множества относительно новых приложений. Дело дошло до того, что правоохранительные органы начали сходить с ума, как показано на слайде ниже.
Немного устаревшие цифры, источник: CSIS (или эта статья)
Заслуживает ли Сноуден похвалы за это? Может быть, не напрямую, но почти наверняка опасения по поводу раскрытой им слежки сыграли свою роль. (Стоит отметить, что это принятие , а не равномерно распределены по всему миру.)
Также стоит отметить, что , по крайней мере, в сообществе с открытым исходным кодом качество нашего программного обеспечения для шифрования значительно улучшилось, в основном благодаря тому, что крупные компании приложили хорошо финансируемые усилия. чтобы укрепить свои системы, отчасти из-за серьезных недостатков, таких как Heartbleed, а отчасти в ответ на собственные опасения компании по поводу слежки.
Очень может быть, что АНБ утратило значительную часть своих возможностей после Сноудена.
Будущее не за американским
Я уже говорил это раньше, как и многие другие: даже если вы поддерживаете миссию АНБ и верите, что США все делают правильно, это не имеет значения. К сожалению, будущее слежки имеет очень мало общего с тем, что происходит в Ft. Мид, Мэриленд. На самом деле, мир, который Сноуден привлек к нашему вниманию, не обязательно является миром, в котором американцы имеют право голоса. Беспроводные сети 5G по всему миру. Это сложный вопрос, и финансовая заинтересованность, вероятно, играет большую роль. Но здесь также важна глобальная безопасность. Этот конфликт, возможно, является самым ясным подтверждением того, что наше собственное правительство знает, насколько важен контроль над сетями связи, и наша неспособность обеспечить безопасность связи в этих сетях может действительно навредить нам. Это означает, что нам здесь, на Западе, лучше собраться, иначе мы должны быть готовы попробовать собственное лекарство.
По крайней мере, мы обязаны Сноудену за то, что он помог нам понять, насколько высоки могут быть ставки.
Автор: Мэтью Гринин Без рубрики 24 сентября 2019 г. 25 сентября 2019 г.
Последние несколько лет были прекрасным временем для развертывания шифрования. За десять лет зашифрованные веб-соединения превратились из новинки в требование для работы современного веб-сайта. Производители смартфонов внедрили шифрование хранилища по умолчанию на миллиардах телефонов. Сквозное шифрование сообщений и телефонных звонков теперь доступно миллиардам пользователей.
Хотя этот прогресс впечатляет криптографов и защитников конфиденциальности, не все видят его таким. Несколько стран, таких как Великобритания и Австралия, приняли законы, пытаясь получить доступ к этим данным, и по крайней мере одно предложение США было передано в Конгресс. Министерство юстиции недавно добавило к ним свой собственный бренд, попросив технологические компании внедрить «ответственное шифрование».
Что такое «ответственное шифрование»? Ну, это небольшая проблема. Никто на стороне правительства в дебатах на самом деле не хотел вдаваться в подробности по этому поводу. На самом деле, недавняя речь заместителя генерального прокурора США Рода Розенштейна умоляла криптографов разобраться в этом.
На этом фоне недавняя статья Яна Леви и Криспина Робинсона из GCHQ читается как глоток свежего воздуха. В отличие от своих американских коллег, британцы в GCHQ — по сути, британском эквиваленте АНБ — похоже, стремятся взаимодействовать с техническим сообществом и выдвигать серьезные идеи. Действительно, Леви и Робинсон в статье выше делают конкретное предложение: они предлагают новое решение, предназначенное для слежки как за зашифрованными сообщениями, так и за телефонными звонками.
В этом посте я расскажу об этом предложении настолько честно, насколько смогу, учитывая, что у меня есть только общее представление об этой идее. Затем я обсужу, что, по моему мнению, может пойти не так.
Краткое иллюстрированное руководство по E2E
Предложение GCHQ касается перехвата правоохранительными органами систем обмена сообщениями и телефонных звонков. Чтобы дать некоторое представление о предложении, мне сначала нужно дать очень краткое (и сверхупрощенное) объяснение того, как на самом деле работают эти системы.
Основная идея любой системы связи E2E заключается в том, что каждый участник шифрует сообщения (или аудио/видеоданные) непосредственно с одного устройства на другое. Этот уровень шифрования снижает необходимость доверять инфраструктуре вашего провайдера — от телефонных линий до серверов и подводных кабелей — что дает дополнительную защиту от злонамеренных поставщиков услуг и хакеров.
Если простить несколько глупых иллюстраций, то на интуитивном уровне получается примерно такая картинка:
Если рассматривать настройку группового чата/звонка, то картинка немного меняется, но незначительно. Каждый участник по-прежнему шифрует данные другим участникам напрямую, минуя провайдера. Фактические детали (конкретные алгоритмы, выбор клавиш) различаются в разных системах. Но концепция остается прежней.
Проблема с приведенными выше упрощенными изображениями заключается в том, что на самом деле в системе E2E происходит гораздо больше, чем просто шифрование.
На практике одной из самых сложных проблем в зашифрованных основах обмена сообщениями является получение ключа, необходимого для фактического выполнения шифрования. Эта проблема, широко известная как распределение ключей , является давней проблемой в области компьютерной безопасности. Есть много способов ошибиться.
Раньше мы просили пользователей управлять своими ключами и обмениваться ими, а затем выбирали, для каких пользователей они хотят выполнять шифрование. Это было ужасно, и все это ненавидели. Современные системы E2E стали популярны во многом потому, что они скрывают все эти детали от своих пользователей. Это происходит за счет некоторой дополнительной инфраструктуры, управляемой провайдером.
На практике такие системы, как Apple iMessage, WhatsApp и Facebook Messenger, на самом деле выглядят примерно так:
Зашифрованный вызов с «системой идентификации», ищущей ключи. Apple представляет внутренние серверы Apple.
Apple в верхней части изображения означает «службу идентификации» Apple, которая представляет собой кластер серверов, работающих в различных центрах обработки данных Apple. Эти серверы выполняют множество задач, но самое главное: они действуют как каталог для поиска ключа шифрования человека, с которым вы разговариваете 9.1219 . Если этот сервис даст осечку и даст вам неверный ключ, лучшие в мире шифры вам не помогут. Вы просто будете шифровать не тому человеку.
Эти службы идентификации выполняют больше, чем поиск ключей. По крайней мере, в некоторых системах группового обмена сообщениями, таких как WhatsApp и iMessage, они также контролируют членство в групповых беседах. В плохо спроектированных системах сервер может добавлять и удалять пользователей из группового разговора по своему желанию, даже если никто из участников не запросил этого. Как будто вы разговариваете в очень уединенной комнате, но дверь не заперта, и управляющий зданием контролирует, кто может войти и присоединиться к вам.
(Техническое примечание: хотя эти два аспекта системы идентификации служат разным целям, на практике они часто тесно связаны. Например, во многих системах существует небольшое различие между «групповым» и «двухучастниковым» обменом сообщениями. Например, в системах, которые поддерживают несколько устройств, подключенных к одной учетной записи, таких как iMessage от Apple, каждое устройство, подключенное к вашей учетной записи пользователя, рассматривается как отдельная сторона в разговоре. При условии, что у любой из сторон есть более одного устройства в их учетной записи [например, , iPhone и iPad] , вы можете придумать каждый разговор iMessage как групповой разговор.)
Большинство систем E2E имеют базовые меры противодействия плохому поведению службы идентификации. Например, клиентские приложения обычно уведомляют вас, когда новый пользователь присоединяется к вашему групповому чату или когда кто-то добавляет новое устройство в ваш аккаунт iMessage. Точно так же и WhatsApp, и Signal раскрывают «номера безопасности», которые позволяют участникам убедиться, что они получили правильные криптографические ключи, что предлагает проверку от недобросовестных поставщиков.
Но эти контрмеры не идеальны, и не каждый сервис их предлагает. Что подводит меня к предложению GCHQ.
Чего хочет GCHQ
В статье Lawfare Леви и Робинсон предложение GCHQ не представлено в мельчайших подробностях. К счастью, оба автора провели большую часть гастролей по США, выступив с несколькими публичными докладами о своих идеях. Я имел честь поговорить с ними обоими в начале этого лета, когда они посетили Университет Джона Хопкинса, так что я думаю, что имею приблизительное представление о том, что они думают.
В общих чертах идея, которую они предлагают, чрезвычайно проста. Цель состоит в том, чтобы воспользоваться существующими недостатками в системах управления идентификацией групповых чатов и систем вызовов. Это позволит правоохранительным органам — при участии поставщика услуг — добавить «призрачного пользователя» (или, в некоторых случаях, «призрачное устройство») в существующий групповой чат или сеанс связи. В системах, где членство в группе может быть изменено инфраструктурой провайдера, это в основном может быть сделано посредством изменений серверных компонентов системы провайдера.
Я говорю, что это может в основном выполняться на стороне сервера, потому что есть нюанс. Даже если вы измените инфраструктуру провайдера, чтобы добавить в беседу неавторизованных пользователей, большинство существующих систем E2E уведомляют пользователей, когда к беседе присоединяется новый участник (или устройство). Вообще говоря, появление незнакомца в вашем разговоре — отличный способ уведомить преступников о том, что игра идет или что у вас есть, поэтому вам обязательно нужно заблокировать это предупреждение.
Хотя в предложении GCHQ нет подробностей, из него следует, что любое работоспособное предложение потребует от поставщиков подавить эти предупреждающие сообщения на целевом устройстве. Это означает, что предложение также потребует изменений в клиентском приложении , а также в инфраструктуре на стороне сервера.
(Некоторые приложения, такие как Signal , уже несколько защищены от этих изменений, поскольку настройка группового чата обрабатывается клиентами с помощью сквозного шифрования/аутентификации. Это не позволяет серверу добавлять новых пользователей без сотрудничества хотя бы одного Однако на данный момент и WhatsApp, и iMessage кажутся уязвимыми для предложенного подхода GCHQ.)
Из-за необходимости значительных модификаций сервера и клиента предложение GCHQ на самом деле представляет собой очень существенное изменение в конструкции систем обмена сообщениями. Кажется вероятным, что изменения кода на стороне клиента должны быть развернуты для всех пользователей, поскольку вы не можете делать целевые обновления программного обеспечения только против преступников. (Или, скорее, если бы вы могли полагаться на такие целевые обновления программного обеспечения, вы бы просто использовали эту возможность вместо того, что предлагает GCHQ.)
Что подводит нас к последнему пункту: как заставить поставщиков согласиться со всем этим?
Хотя оптимизм и сотрудничество в принципе хороши, маловероятно, что провайдеры связи намерены добровольно встроить в свои зашифрованные услуги мощную возможность прослушивания, хотя бы потому, что это представляет собой масштабную и рискованную модификацию. Предположительно это означает, что правительству Великобритании придется принудить к сотрудничеству. Одним из возможных путей для этого является использование Уведомлений о технических возможностях в соответствии с Законом Великобритании о полномочиях на проведение расследований. Эти уведомления обязывают провайдера предлагать расшифровку в режиме реального времени для групп пользователей от 1 до 10 000 пользователей, и, кроме того, провайдеры должны проектируют свои системы таким образом, чтобы такая возможность оставалась доступной.
И вот в чем проблема.
Провайдеры уже закрывают эту лазейку
Настоящая проблема с предложением GCHQ заключается в том, что оно направлено на уязвимость в системах обмена сообщениями/вызовами, которая уже хорошо известна провайдерам, и, кроме того, уязвимость, над устранением которой провайдеры работали — , возможно, потому, что они беспокоятся, что кто-то вроде GCHQ (или, возможно, намного хуже) попытается его использовать. Сделав это предложение, люди из GCHQ фактически гарантировали, что эти провайдеры будут двигаться намного быстрее.
И в их распоряжении довольно много вариантов. За последние несколько лет исследователи предложили несколько вариантов дизайна, обеспечивающих прозрачность для пользователей в отношении того, какие ключи они получают от службы идентификации поставщика. Эти системы работают за счет того, что служба идентификации фиксирует ключи, связанные с отдельными пользователями, поэтому провайдеру очень сложно изменить ключи пользователя (или добавить устройство) незаметно для всех в мире.
Как упоминалось выше, продвинутые мессенджеры, такие как Signal, «погрузили» управление групповым чатом в зашифрованный поток связи, так что сервер не может добавлять новых пользователей без подтверждения цифровой аутентификации одного из существующих участников. Этот дизайн, если его портировать на более популярные сервисы, такие как WhatsApp, может убить предложение GCHQ.
Конечно, эти решения подчеркивают сложный характер предложения GCHQ. Обратите внимание, что для того, чтобы воспользоваться существующими уязвимостями, GCHQ потребуется, чтобы поставщики меняют свою систему. И, конечно же, если вы открыли дверь для принуждения провайдеров к изменению своей системы, зачем останавливаться на небольших изменениях? Что мешает правительству Великобритании, скажем, сделать еще один шаг и использовать силу закона, чтобы заставить провайдеров , а не усилить защиту своих систем от такого типа атак ?
Что подводит нас к реальной проблеме с предложением GCHQ. Насколько я вижу, возможны два исхода. Во-первых, провайдеры быстро укрепляют свою систему — и это хорошо! — и в процессе устранить уязвимости, которые делают предложение GCHQ жизнеспособным (что плохо, по крайней мере, для GCHQ). Чем больший интерес правительства проявляют к этому предложению, тем более вероятен этот первый результат. Во втором случае правительство Великобритании, возможно, наряду с другими правительствами, решит эту проблему на 9 1218 вынуждает провайдеров держать свои системы уязвимыми. Меня беспокоит второй результат.
Говоря более конкретно, сегодняшние системы действительно содержат существующие недостатки, которыми легко воспользоваться. Но это не значит, что мы должны замуровывать эти недостатки в бетоне. И как только правоохранительные органы начнут полагаться на них, мы фактически это сделаем. Со временем то, что кажется «скромным предложением» с использованием текущих недостатков, быстро станет окостеневшим влиянием, удерживающим старые недостатки на месте. В худшем случае мы будем назначать такие агентства, как GCHQ, главным архитектором коммуникационных систем Apple и Facebook.
Это плохой результат. На самом деле, это то, что, вероятно, замедлит прогресс на долгие годы.
Автор: Мэтью Гринин Без рубрики 17 декабря 2018 г. 20 декабря 2018 г.
Уже больше года этот блог не может выполнить главное обещание — что когда-нибудь появятся фотографии такс. Сегодня доставляем.
Это Калли (сокращенно от Каллиопа), которая прорабатывает летнее криптографическое чтение:
Но иногда это утомительно и нужно сделать перерыв.
Визит странной металлической таксы:
Лето:
И в память о Зое и Софи, которые помогли мне начать этот блог.

Мэтью Гринин Без рубрики 27 июля 2018 г. 23 июля 2018 г. 73 Words
Это продолжение поста из части 1. Обратите внимание, что это незавершенная работа, и в ней могут быть некоторые ошибки 🙂 Я постараюсь исправить их по мере продвижения.
В предыдущем посте я обсуждал проблему создания CCA-безопасного шифрования с открытым ключом. Вот краткое изложение того, что мы обсуждали в первой части:
Мы рассмотрели определение безопасности CCA2.
Мы описали, как легко добиться этого в настройке симметричного шифрования с использованием схемы шифрования CPA-secure и безопасного MAC-адреса.
Мы говорили о том, почему тот же подход не работает для стандартного шифрования с открытым ключом.
В этом посте я собираюсь обсудить несколько различных методов, которые на самом деле обеспечивают безопасность CCA для шифрования с открытым ключом. Мы рассмотрим их в произвольном порядке.
Краткое примечание о доказательствах безопасности. Очевидно, существует множество различных способов попытаться взломать схему безопасности CCA2 из разных компонентов. Некоторые из них могут быть безопасными, а могут и не быть. В общем, ключевое различие между «безопасной» и «возможно безопасной» схемой заключается в том, что мы можем создать для нее какое-то доказательство безопасности.
Фраза «какой-то» окажется важным предостережением, потому что эти доказательства могут потребовать некоторого обмана.
Плохое и уродливое
Прежде чем мы перейдем к конструктивным деталям, стоит немного поговорить о некоторых идеях, которые не работают для обеспечения безопасности CCA. Лучше всего начать с некоторых ранних схем заполнения RSA, в частности со стандарта заполнения PKCS#1v1.5.
Прокладка PKCS#1 была разработана в 1980-х, когда было очевидно, что шифрование с открытым ключом получит широкое распространение. Он был задуман как этап предварительной обработки сообщений, которые должны были быть зашифрованы с использованием открытого ключа RSA.
Эта схема заполнения имела две особенности. Во-первых, он добавил случайных чисел к сообщению перед его шифрованием. Это было разработано для отражения простых атак с угадыванием зашифрованного текста, которые исходят от детерминированных схем шифрования, таких как RSA. Легко показать, что рандомизированное шифрование абсолютно необходимо для любой схемы безопасного шифрования с открытым ключом IND-CPA (и неявно IND-CCA). Во-вторых, заполнение добавило несколько «проверочных» байтов, которые должны были помочь обнаружить искаженные зашифрованные тексты после расшифровки; это было разработано (предположительно) для защиты схемы от недопустимых попыток дешифрования.
PKCS#1v1.5 по-прежнему широко используется в протоколах, включая все версии TLS до TLS 1.3. На приведенной ниже диаграмме показано, как выглядит схема заполнения при использовании в TLS с 2048-битным ключом RSA. Раздел, помеченный как «48 байт PMS» (pre-master secret), в этом примере представляет собой зашифрованный открытый текст. 205 «ненулевое заполнение» состоит из чисто случайных байтов, исключающих байт «0», потому что это значение зарезервировано для указания конца раздела заполнения и начала открытого текста.
После использования секретного ключа RSA для восстановления дополненного сообщения дешифратор должен проанализировать сообщение и убедиться, что первые два байта («00 02») и граничный байт «00» все верны и не нарушение каких-либо правил. Дешифратор может опционально проводить другие проверки, например, проверять длину и структуру открытого текста, если это известно заранее.
Одно из первых замечаний по поводу PKCS#1v1. 5 заключается в том, что разработчики вроде как интуитивно понял , что атака с выбранным шифротекстом — это вещь. Они явно добавили несколько небольших проверок, чтобы убедиться, что злоумышленнику будет сложно изменить заданный зашифрованный текст (например, умножив его на выбранное значение). Также очевидно, что эти проверки не очень сильны. В стандартизированной версии схемы заполнения необходимо проверить три байта — и один из них (байт «00» после заполнения) может «плавать» в большом количестве различных позиций, в зависимости от того, сколько заполнения и открытого текста есть в сообщении.
Использование слабой проверки целостности приводит к мощной атаке CCA2 на схему шифрования, впервые обнаруженную Даниэлем Блейхенбахером. Атака является мощной из-за того, что она фактически использует проверку заполнения как способ получения информации об открытом тексте. То есть: злоумышленник «искажает» зашифрованный текст и отправляет его на расшифровку, полагаясь на тот факт, что расшифровщик просто выполнит проверки дешифрования они должны выполнять — и выводить заметную ошибку в случае сбоя. Имея только один бит информации на расшифровку, атака может постепенно восстановить полный открытый текст конкретного зашифрованного текста путем (а) умножения его на некоторое значение, (б) отправки результата для расшифровки, (в) записи успеха/неудачи результат, (d) адаптивный выбор нового значения и повторение шага (a) много тысяч или миллионов раз.
Схема заполнения PKCS#1v1.5 в основном ценна для нас сегодня, потому что она служит отличным предупреждением для инженеров-криптографов, которые в противном случае продолжали бы следовать школе создания протоколов «вы можете просто взломать что-то, что выглядит безопасным». Атаки в стиле Блейхенбахера в значительной степени напугали криптосообщество. Вместо того, чтобы продолжать использовать этот подход, криптосообщество (в основном) перешло к методам, которые, по крайней мере, предлагают некоторое подобие доказуемая безопасность .
Об этом мы поговорим чуть позже.
Несколько кратких заметок о реализации шифрования с открытым ключом, защищенного CCA2 схема.
Исторически сложилось два общих требования:
Было бы очень удобно, если бы мы могли начать с существующей схемы шифрования, такой как шифрование RSA или Elgamal, и в целом настроить (или «скомпилировать») эту схему в схему безопасности CCA2. (Общие методы многократного использования — особенно полезно в случае, если кто-то придумает новые базовые схемы шифрования, например постквантово-защищенные.)
Полученная схема должна быть довольно эффективной. Это исключает большинство ранних теоретических методов , которые используют огромные доказательства с нулевым разглашением (какими бы крутыми они ни были).
Прежде чем мы перейдем к деталям, я также хочу повторить интуитивное описание игры в безопасность CCA2, которое я дал в предыдущем посте. Игра (или «эксперимент») работает так:
Я создаю пару ключей шифрования для схемы с открытым ключом и даю вам открытый ключ.
Вы можете посылать мне (последовательно и адаптивно) множество зашифрованных текстов, которые я расшифрую своим секретным ключом. Я дам вам результат каждой расшифровки.
В конце концов, вы пришлете мне пару сообщений (одинаковой длины), и я выберу часть наугад и верну вам шифрование, которое я обозначу как .
Вы повторите шаг (2), отправив мне зашифрованные тексты для расшифровки. Если вы пришлете мне , я отклоню вашу попытку. Но я расшифрую любой другой зашифрованный текст, который вы мне пришлете, даже если он лишь немного отличается от .
Вы (злоумышленник) выведете свое предположение . Они «выиграют» игру, если .
Мы говорим, что схема защищена по стандарту IND-CCA2, если атакующий выигрывает с вероятностью, «ненамного превышающей» 1/2 (это лучшее, что может сделать злоумышленник, если он просто угадывает случайным образом).
Беглый просмотр этого определения показывает, что нам нужна схема шифрования CCA2, чтобы обеспечить как минимум две основные функции.
Во-первых, должно быть очевидно, что схема не должна пропускать информацию о секретном ключе, , даже когда я использую его для расшифровки произвольно выбранных зашифрованных текстов по вашему выбору. Очевидные примеры схем, не отвечающих этому требованию: наиболее известной является криптосистема Рабина (учебник), в которой способность злоумышленника получить расшифровку одного выбранного зашифрованного текста может привести к утечке всего секретного ключа.
Более тонко, кажется очевидным, что безопасность CCA2 связана с негибкостью . Вот почему: предположим, я получил зашифрованный текст вызова на шаге (3). Должно быть так, что я не могу легко «превратить» этот зашифрованный текст в новый зашифрованный текст, который содержит тесно связанный открытый текст (и который претендент сможет и захочет осмысленно расшифровать). Легко заметить, что , если бы мне сошло с рук это , по правилам игры я, вероятно, мог бы выиграть на шаге (4), просто отправив его на расшифровку, получив результат и посмотрев, является ли он более тесно связанным с или . (На самом деле это очень слабое объяснение того, что делает атака Блейхенбахера.)
Оказывается, еще более сильным свойством, которое помогает достичь обоих этих условий, является то, что называется осведомленностью об открытом тексте. Существуют различные слегка отличающиеся друг от друга математические формулировки этой идеи, но здесь я попытаюсь дать только англоязычную интуицию:
Если злоумышленник может отправить (действительный) зашифрованный текст для расшифровки, это должно быть так, что он уже знает открытый текст этого сообщения.
Эта гарантия очень мощная, потому что она помогает нам быть уверенными, что процесс расшифровки не даст злоумышленнику новую информацию, которой у него еще нет. Она может отправлять любые сообщения, которые хочет (включая испорченный зашифрованный текст вызова), но если это свойство осведомленности об открытом тексте выполняется в самом строгом смысле, эти расшифровки не сообщат ей ничего, чего она еще не знает.
Конечно, только потому, что ваша схема удовлетворяет вышеуказанным условиям, не означает, что она безопасна. Оба приведенных выше правила являются эвристиками : то есть они являются необходимыми условиями для предотвращения атак, но они могут быть или не быть достаточными . Чтобы действительно доверять схеме (в криптографическом смысле), мы должны быть в состоянии предложить доказательство (при некоторых предположениях), что эти гарантии выполняются. Мы рассмотрим это немного по мере продвижения вперед.
Методика 1: Оптимальное заполнение асимметричного шифрования
Одно из первых практичных преобразований CCA2 было разработано Белларом и Рогауэем в качестве прямой замены схемы заполнения PKCS#1v1.5 в шифровании RSA. Разработанная ими схема, называемая Оптимальное заполнение асимметричным шифрованием, представляет собой «вставную» замену более ранней, неработающей схемы заполнения версии 1.5. Он также имеет доказательство безопасности. (В основном. Мы еще вернемся к этому последнему пункту.)
(Как ни странно, OAEP был включен в стандарты PKCS#1 версии 2.0, поэтому иногда вы увидите, что он упоминается как PKCS#1v2.0-OAEP. .)
Наиболее очевидным преимуществом OAEP по сравнению с предыдущим уровнем техники является добавление не одной, а двух отдельных хеш-функций, которых не было в предыдущей версии 1. 5. (Иногда их называют «функциями генерации маски», что является просто причудливым способом сказать, что они являются хеш-функциями с выходными данными произвольного выбранного размера. Такие функции можно легко построить из существующих хеш-функций, таких как SHA256.)
Выраженный графически, OAEP выглядит следующим образом:
Функция заполнения OAEP (любезно предоставлено Озгой из Википедии). Сообщение m и r представляет собой строку случайных битов. «000» представляет собой «контрольную строку», состоящую из строки k1 «0» битов. Длины k0, k1 выбираются схемой, а общая длина входных данных должна быть наибольшей битовой (или байтовой) строкой, которая может поместиться внутри модуля RSA (например, 1024 бита). Некоторые 0 бит/байтов могут быть добавлены к результату, если дополненный результат меньше модуля.
Если вы когда-нибудь видели шифр DES, эта структура должна показаться вам знакомой. По сути, OAEP представляет собой сеть Фейстеля с двумя раундами (без ключа), которая использует пару хеш-функций для реализации функций раунда. Есть несколько ключевых замечаний, которые вы можете сделать сразу же:
Просто взглянув на диаграмму выше, вы можете увидеть, что очень легко вычислить эту функцию заполнения вперед (переходя от открытого текста и некоторого случайного заполнения к дополненному сообщению). ) и наоборот — то есть это легко обратимая перестановка. Ключом к этой функции является структура сети Фейстеля.
После расшифровки дешифратор может инвертировать заполнение заданного сообщения и убедиться, что «контрольная строка» (строка из k1 «0» битов) правильно структурирована. Если эта строка неправильно структурирована, дешифратор может просто выдать ошибку. Это включает в себя первичную проверку дешифрования.
Принимая во внимание некоторые (сильные) свойства хеш-функций, интуитивно кажется, что преобразование OAEP предназначено для создания своего рода «лавинного эффекта», когда даже небольшая модификация дополненного сообщения приведет к очень разных незаполненных результатов при инвертированном преобразовании. На практике любая такая модификация с большой вероятностью должна «выбросить» контрольную строку.
С интуитивной точки зрения, последние два свойства делают OAEP защищенным от атак с выбранным зашифрованным текстом. Идея заключается в том, что из-за случайных свойств хэш-функции злоумышленнику должно быть сложно построить действительный зашифрованный текст (тот, который имеет правильную проверочную строку), если он еще не знает открытый текст, который входит в преобразование. . Это должно сохраняться, даже если у злоумышленника уже есть какой-то известный действительный зашифрованный текст (например), который он хочет взломать.
В частности, в отношении взлома: если я отправлю зашифрованный текст RSA-OAEP, который шифрует конкретное сообщение, злоумышленник не сможет легко преобразовать этот зашифрованный текст в другой зашифрованный текст, который все равно пройдет проверки дешифрования. Это связано с двумя фактами: (1) поскольку RSA является перестановкой (с лазейкой), любое изменение неявно изменит дополненное сообщение, которое вы восстанавливаете после инвертирования функции RSA. И (2) отправка этого измененного дополненного сообщения в обратном направлении через преобразование OAEP должна с огромной вероятностью испортить контрольную строку (и сообщение). В результате противник не может взломать чужой зашифрованный текст.
Все это предполагает некоторые очень сильные предположения о хеш-функциях, которые мы обсудим ниже.
Детали подтверждения OAEP (на самом смехотворно поверхностном уровне)
Доказательство безопасности OAEP требует двух основных методов. Оба фундаментально полагаются на представление о том, что функции и являются 91 218 случайными оракулами. Это важно по двум совершенно разным причинам.
Во-первых: предположение о том, что функция является «случайным оракулом», означает, что мы предполагаем, что она ведет себя так же, как случайная функция. это удивительных свойств для хэш-функции! (Примечание: у реальных хеш-функций нет . Это означает, что гипотетически они могут иметь очень «неслучайное» поведение, которое сделает RSA-OAEP небезопасным. На практике это еще не было практической проблемой для реальных реализаций OAEP. , но это стоит иметь в виду.
Легко видеть, что если бы хэш-функции и были случайными функциями , это придало бы OAEP некоторые очень мощные свойства. Помните, что одна из основных интуитивных целей схемы OAEP — предотвратить злоумышленники не смогут успешно заставить вас расшифровать неправильно сконструированный (например, искаженный) зашифрованный текст. Если обе хеш-функции действительно случайны, это означает, что любой недействительный зашифрованный текст будет почти наверняка не удастся расшифровать , потому что проверка заполнения не удастся.
На гораздо более глубоком уровне использование случайных оракулов в доказательстве безопасности RSA дает снижению безопасности большую «дополнительную мощность» для обработки таких вещей, как расшифровка выбранных зашифрованных текстов. Это связано с тем, что в случайном доказательстве оракула редукция доказательства позволяет как «видеть» каждое значение, хэшированное с помощью этих хеш-функций, так и «программировать» функции так, чтобы они давали определенные выходные данные. Это было бы невозможно, если бы и были реализованы с использованием реальных хеш-функций, и поэтому все доказательства безопасности были бы нарушены.
Эти свойства предоставляют инструмент в доказательстве безопасности для обеспечения расшифровки даже в том случае, когда секретный ключ неизвестен . В традиционном доказательстве схемы RSA-OAEP идея состоит в том, чтобы показать, что злоумышленник, взламывающий шифрование (в смысле IND-CCA2), может быть использован для создания второго злоумышленника, решающего проблему RSA. Это делается путем взятия некоторых случайных значений, где открытый ключ RSA с неизвестной факторизацией, и «программирования» случайных оракулов таким образом, что . Интуитивная идея состоит в том, что злоумышленник, который может узнать что-то о базовом сообщении, должен запросить функции и правильные входные данные, что в конечном итоге позволит снижению безопасности получить RSA, обратный тому, даже если сокращение не знает секретный ключ RSA. , то есть такой злоумышленник позволит нам найти целое число такое, что .
(Оказалось, что в оригинальном доказательстве OAEP были некоторые проблемы, из-за которых оно не совсем работало для произвольных перестановок лазейки . Shoup исправила их, предоставив новую схему заполнения под названием OAEP+, но исходный OAEP с тех пор исчез. в интенсивное использование в рамках стандартов!Оказывается, что RSA-OAEP работает, однако, для RSA с общедоступными показателями 3 и другими показателями, хотя для доказательства этого потребовались некоторые уродливые пластыри.Вся эта история является частью предостережения о доказуемой безопасности , который Коблиц обсуждает здесь.)
Методика 2: Преобразование Фуджисаки-Окамото
Одним из ограничений заполнения OAEP (и OAEP+) является то, что для его работы требуется лазейка перестановка . Это хорошо относится к шифрованию RSA, но не обязательно работает со всеми существующими схемами шифрования с открытым ключом. Это мотивирует потребность в других преобразованиях CCA, которые работают с произвольными существующими (не-CCA) схемами шифрования.
Одна из лучших универсальных методик для построения CCA2-безопасного шифрования с открытым ключом принадлежит Эйичиро Фуджисаки и Тацуаки Окамото. Идея этого преобразования состоит в том, чтобы начать со схемы, которая уже соответствует определению безопасности IND-CPA, то есть она семантически безопасна, но не против выбранных атак зашифрованного текста. (Для этого описания нам также потребуется, чтобы эта схема имела большое пространство сообщений [экспоненциального размера] и некоторые специфические свойства, связанные со случайностью.) Прелесть «преобразования Фудзисаки-Окамото» (далее: F-O) заключается в том, что как и OAEP до него, при наличии работающей схемы шифрования с открытым ключом требуется только добавление некоторых хеш-функций, и его безопасность может быть доказана в модели случайного оракула.
Давайте представим, что у нас есть алгоритм шифрования с открытым ключом IND-CPA, состоящий из алгоритмов . Мы также будем использовать две независимые хеш-функции.
Ключевым наблюдением здесь является то, что в каждой схеме шифрования с открытым ключом IND-CPA (семантически безопасной) алгоритм является рандомизированным . На самом деле это вместо из-за определения IND-CPA. (См. здесь обсуждение того, почему это так.) Говоря более явно, это означает, что алгоритм шифрования должен иметь доступ к некоторому набору случайных битов, которые будут использоваться для создания зашифрованного текста.
Основная уловка, которую использует F-O преобразование, состоит в дерандомизации этого алгоритма шифрования с открытым ключом. Вместо того, чтобы использовать реальные случайные биты для шифрования, он будет использовать выходные данные хэш-функции для создания случайных битов, которые будут использоваться для шифрования. Это превращает рандомизированное шифрование в детерминированное. (Это, конечно, требует, чтобы и входные данные, и внутренние компоненты были способны производить биты, которые «выглядят» случайными. )
Давайте перейдем к гайкам и болтам. Преобразование F-O вообще не меняет алгоритм генерации ключей исходной схемы шифрования, за исключением указания хеш-функций. Основные изменения касаются новых алгоритмов шифрования и дешифрования. Я приведу один вариант трансформации, хотя есть и другие. Этот работает следующим образом.
Чтобы зашифровать сообщение, которое мы представим в виде некоторой последовательности битов фиксированной длины:
Вместо того, чтобы шифровать фактическое сообщение, мы вместо этого выбираем случайное сообщение из пространства сообщений исходной схемы CPA-secure. .
Мы хешируем случайное сообщение вместе с исходным сообщением, используя эту первую хеш-функцию. Вывод этой функции даст нам «случайную» битовую строку. Обозначим это как: .
Далее мы зашифруем новое случайное сообщение, используя оригинальный (CPA-secure) алгоритм схемы шифрования, но важно: мы будем использовать биты в качестве случайности для этого шифрования . Результатом этого процесса будет первая часть зашифрованного текста: . Обратите внимание, что здесь речь идет только о случайности алгоритма шифрования, а не о самом зашифрованном сообщении.
Наконец, мы получаем «ключ» для шифрования реального сообщения, которое мы хотим отправить. Мы можем вычислить это как .
Теперь мы зашифровываем исходное сообщение, которое хотим отправить, используя какую-нибудь безопасную схему шифрования, например простой одноразовый блокнот: .
Выводим «зашифрованный текст».
Чтобы расшифровать , мы должны выполнить следующие шаги:
Во-первых, использовать секретный ключ исходной схемы шифрования с открытым ключом для расшифровки зашифрованного текста , который (если все в порядке) должен дать нам .
Теперь используйте знание для восстановления ключа и, таким образом, сообщения, которое мы можем получить как .
Теперь проверьте правильность обоих, повторно вычислив случайность и проверив условие. Если эта окончательная проверка не удалась, просто выведите ошибку расшифровки.
Уф. Так что, черт возьми, здесь происходит?
Давайте рассмотрим эту схему с практической точки зрения. Ранее в этом посте мы говорили, что для обеспечения безопасности IND-CCA2 схема должна иметь две функции. Во-первых, он должен быть осведомлен об открытом тексте , , что означает, что для создания действительного зашифрованного текста (который проходит все проверки дешифрования) злоумышленник должен уже знать открытый текст.
Есть ли у Ф-О это свойство? Ну, интуитивно мы бы надеялись что ответ «да». Обратите внимание, что для некоторого допустимого зашифрованного текста F-O расшифрованный открытый текст неявно определяется как . Итак, что мы действительно хотим доказать, так это то, что для создания действительного зашифрованного текста злоумышленник должен уже знать и до отправки сообщения для расшифровки.
Эта гарантия (с высокой вероятностью) исходит из структуры . Чтобы зашифрованный текст считался дешифрователем действительным, он должен удовлетворять проверке. Идея этого доказательства состоит в том, что злоумышленнику должно быть трудно построить такое, если он предварительно не вызвал хеш-функцию на входе. Если она вызвала хеш-функцию для получения этой части зашифрованного текста, то она уже знает эти значения, и оракул дешифрования не предоставляет ей никакой дополнительной информации, которой у нее уже не было. (В качестве альтернативы, если она сделала , а не вызывают хеш-функцию, то вероятность ее выполнения должна быть чрезвычайно низкой.)
Конечно, это только одна стратегия, доступная злоумышленнику. Она также могла взломать существующий зашифрованный текст, например . В этом случае ее стратегия двояка: она может подделать первую часть зашифрованного текста и/или она может подделать вторую. Но легко увидеть, что это приведет к нарушению некоторой части проверок дешифрования:
Если она подделает какой-либо бит , она изменит восстановленное сообщение на новое значение, которое мы можем вызвать . Однако это, в свою очередь, (с большой вероятностью) приведет к тому, что дешифратор будет восстанавливать очень разные случайные монеты, чем те, которые использовались в исходной конструкции , и, таким образом, проверка расшифровки этой части, вероятно, не удастся. 9* = {\sf Encrypt}(pk, M’; r’) не должно проходить, и расшифровка просто выдаст ошибку.
Конечно, она может попытаться подделать обе части зашифрованного текста. Но это казалось бы еще более сложной задачей.
Проблема с приведенным выше упражнением заключается в том, что ни одно из них не является доказательством того, что подход работает. В этом споре очень много 91 218 должно быть 91 219 и 91 218, вероятно, 91 219, и ничто из этого не должно вас сильно радовать. Грубый набросок доказательства схемы FO можно найти здесь. (Предупреждаю вас, что в нем, вероятно, есть некоторые ошибки, и я предлагаю это в основном как интуиция.)
Схема F-O имеет множество вариантов. Несколько иной и гораздо более формальный подход Hofheinz и Kiltz можно найти здесь, и он касается некоторых других требований к базовой схеме CPA-безопасности.
Продолжение следует…
До сих пор в этом обсуждении мы рассмотрели два основных метода — оба на очень поверхностном уровне — которые обеспечивают безопасность CCA2 при смехотворно сильном предположении, что случайные оракулы существуют. К сожалению, нет. Это мотивирует потребность в более совершенных подходах, которые вообще не требуют случайных оракулов.
Есть пара таких, которыми, к сожалению, никто не пользуется. Им придется подождать до следующего поста.
Автор: Мэтью Гринин Без рубрики 20 июля 2018 г. 21 апреля 2019 г.
TL;DR. Нет. Или продолжайте читать, если хотите.
В понедельник группа исследователей из Мюнстера, RUB и NXP обнаружила серьезные криптографические уязвимости в ряде зашифрованных почтовых клиентов. Недостатки, известные под симпатичным названием уязвимости «Efail», потенциально позволяют злоумышленнику расшифровать электронную почту, зашифрованную с помощью S/MIME или PGP, с минимальным взаимодействием с пользователем.
По стандартам криптографических уязвимостей это самое ужасное. Вкратце: если злоумышленник может перехватить и изменить зашифрованное электронное письмо — скажем, отправив вам новую (измененную) копию или изменив копию, хранящуюся на вашем почтовом сервере, — он может заставить многие почтовые клиенты с графическим интерфейсом отправить полную открытый текст электронной почты на контролируемый злоумышленником сервер . Хуже того, большинство основных проблем, вызывающих этот недостаток, известны уже много лет, но до сих пор остаются у клиентов.
Большая (и в значительной степени заниженная) история EFail — это то, как он влияет на S/MIME. Этот «корпоративный» протокол электронной почты одновременно (1) ненавидят все криптосообщество, потому что он ужасен и имеет косую черту в названии, и все же (2) , вероятно, является наиболее широко используемым протоколом шифрования электронной почты в корпоративной среде. мир. Таблица справа — выдержка из статьи — дает представление о том, как Efail влияет на клиентов S/MIME. TL;DR это очень плохо на них влияет.
Efail также влияет на меньшее, но нетривиальное количество клиентов, совместимых с OpenPGP. Как и следовало ожидать (если кто-то проводил время с людьми, любящими PGP), раскрытие этих уязвимостей вызвало некоторую негативную реакцию в HN и среди людей, которые делают и любят клиенты OpenPGP. В основном по причинам, которые не очень оправданны.
Поэтому вместо того, чтобы писать о забавных вещах, таких как создание гаджетов CFB и CBC, сегодня я собираюсь написать о чем-то гораздо менее захватывающем: о проблеме уязвимость раскрытие в таких экосистемах, как PGP. И как плохая реакция на раскрытие информации может навредить всем нам.
Как Efail был раскрыт сообществу PGP
Составление полного графика процесса раскрытия Efail, вероятно, было бы скучным и трудоемким проектом. К счастью, Томас Птачек любит скучные и трудоемкие проекты и уже сделал это за нас.
Вкратце, первое раскрытие Efail поставщикам началось 9 октября прошлого года. 1219, более чем за 200 дней до согласованной даты публикации. Авторы уведомили о большом количестве уязвимых клиентов с графическим интерфейсом PGP, а также уведомили проект GnuPG (от которого зависят многие из этих проектов) самое позднее к февралю. Из того, что я могу сказать, каждый крупный поставщик согласился сделать какой-то патч. GnuPG решил, что это не их вина, и фактически прекратил переписку.
Все стороны согласились публично не обсуждать уязвимость до согласованной даты в апреле, которая позже была перенесена на 15 мая. Исследователи также уведомили EFF и некоторых журналистов, находящихся под эмбарго, но никто из них ничего не слил. 14 мая кто-то отправил ошибку в список рассылки. Поэтому EFF разместил уведомление об уязвимости (которое мы обсудим чуть подробнее ниже), а исследователи создали веб-сайт. Это почти вся история.
По поводу разоблачения Efail ходят три основных обвинения. Их можно резюмировать следующим образом: (1) поддерживать эмбарго при скоординированном раскрытии информации действительно сложно, (2) раскрытие EFF «несправедливо» заставило это звучать как серьезная уязвимость, «когда это не так», и (3) все уже было исправлено. так что в чем проблема .
Раскрытие информации затруднено; особенно скоординированные
Я участвовал в двух раскрытиях недостатков в открытых протоколах шифрования. (Оба были проблемами TLS.) Каждый из них ставит неразрешимую дилемму. Вам нужно одновременно (a) убедитесь, что каждый поставщик имеет как можно более заблаговременное уведомление, чтобы они могли исправить свое программное обеспечение. Но в то же время (б) нужно избегать говорить буквально никому, , потому что в Интернете ничего не остается секретным. В какой-то момент вы уведомите какой-нибудь проект FOSS, который использует открытый список рассылки разработчиков или сервер заявок, и вся проблема просочится наружу.
Раскрытие ошибок, затрагивающих PGP, особенно опасно. Это потому, что нет такого понятия, как «PGP». Вместо этого у нас есть большое и распределенное сообщество, которое вращается вокруг протокола OpenPGP. Основой этого сообщества является проект GnuPG, который поддерживает основной инструмент и библиотеки GnuPG, на которые полагаются многие клиенты. Кроме того, есть множество нишевых клиентов с графическим интерфейсом и проекты плагинов электронной почты. Наконец, есть коммерческие поставщики, такие как Apple и Microsoft. (Кто в основном занимается S/MIME и может неохотно разрешать плагины PGP.)
Затем, конечно, есть тысячи конечных пользователей, которые, как правило, не обновляют свое программное обеспечение, если не произойдет что-то действительно плохое и заслуживающее внимания.
Очевидным решением проблемы раскрытия информации является поэтапное раскрытие. Сначала вы уведомляете крупных коммерческих поставщиков, так как именно там находится большинство затронутых пользователей. Затем вы прокладываете себе путь по «длинному хвосту» проектов с открытым исходным кодом, зная, что эмбарго неизбежно может быть нарушено, и всем придется в спешке вносить исправления. И вы помните, что , что бы ни случилось, все будут обвинять вас в том, что вы запороли раскрытие информации.
Что касается проблем с PGP в Efail, крупными поставщиками клиентов являются Mozilla (Thunderbird), Microsoft (Outlook) и, возможно, Apple (Mail). Следующим очевидным выбором будет исправление инструмента GnuPG, чтобы он больше не выдавал неаутентифицированный открытый текст , который является корнем многих проблем в Efail.
Похоже, команда Efail использовала именно этот подход для устранения уязвимостей на стороне клиента. К сожалению, команда GnuPG приняла решение, что не в их обязанности входит упреждающее решение проблем, которые они рассматривают как «неправомерное использование клиентами GnuPG API» (мой пересказ), даже если такое неправильное использование широко распространено среди многих клиентов, использующих их инструмент. Таким образом, наиболее очевидное решение одной части проблемы было недоступно.
Вероятно, это самая неприятная часть истории с Efail, потому что в этом случае очень сильно виновата GnuPG. Их API делает то, что напрямую нарушает передовой опыт в области криптографии , а именно, выпускает неаутентифицированный открытый текст перед созданием сообщения об ошибке. И хотя это можно понимать как разумный дизайн API во время разработки, продолжение поддержки этого API, даже если клиенты регулярно используют его неправильно, теперь привело к недостаткам во всей экосистеме. Отказ GnuPG взять на себя ведущую роль в превентивной защите этих уязвимостей увеличивает сложность обнаружения этих недостатков и увеличивает вероятность возникновения проблем в будущем.
Так что же пошло не так с раскрытием Efail?
Несмотря на то, что вы, возможно, слышали, учитывая сложность этого раскрытия, очень мало что пошло не так. Основные проблемы, поднятые людьми, похоже, связаны с содержанием поста EFF. И с некоторыми действительно плохими сообщениями от Роберта Дж. Хансена в проекте Enigmail (и GnuPG).
Почта EFF. Исследователи Efail решили использовать Electronic Frontier Foundation в качестве основного источника для объявления о существовании уязвимости сообществу конфиденциальности. Это вряд ли кажется необоснованным, потому что EFF обычно считается надежным брокером и обращается к нужному сообществу (по крайней мере, здесь, в США).
Сообщение EFF не содержит подробностей и списка затронутых (или исправленных) клиентов. Он дает две довольно мягкие рекомендации:
Временно отключите или удалите существующие клиенты, пока не убедитесь, что они исправлены.
Может быть, стоит подумать об использовании более современной криптосистемы, такой как Signal, по крайней мере до тех пор, пока вы не будете уверены, что ваш PGP-клиент снова в безопасности.
Это, естественно, вызвало огромное волнение у многих в сообществе PGP. Некоторые люди, в том числе поставщики, неверно истолковали сообщение EFF как по существу подталкивающее людей к «навсегда» удалить PGP, что «поставит под угрозу жизни», потому что, по-видимому, эти пользователи (чья жизнь находится в опасности, помните) будут немедленно удалены.1218 возвращаются к отправке компрометирующей информации с помощью текстовых электронных писем — вместо того, чтобы временно переключаться на один из нескольких современных, хорошо изученных безопасных мессенджеров или просто не отправлять электронные письма в течение нескольких часов.
Если вы думаете, что я преувеличиваю, вот одна реакция от ProtonMail:
Самая разумная критика, которую я слышал о сообщении EFF, заключается в том, что в нем не содержится много подробностей о том, какие клиенты пропатчены, и которые уязвимы. Предположительно, у кого-то может сложиться впечатление, что эта уязвимость все еще присутствует в их почтовом клиенте, и поэтому они будут чувствовать себя менее чем в безопасности при ее использовании.
Честно говоря, для меня звучит как очень хороший результат. Проблема с Efail заключается в том, что не имеет значения, защищен ли ваш клиент. Уязвимость Efail может повлиять на вас, если хотя бы один из ваших партнеров по общению использует небезопасный клиент.
Излишне говорить, что я не очень сочувствую реакции на пост EFF. Если вы не можете быть уверены, что ваш клиент защищен, вы, вероятно, должны чувствовать себя неуверенно.
Плохая связь с GnuPG и Enigmail. На дату раскрытия любой, кто ищет точную информацию о безопасности двух крупных проектов — GnuPG и Enigmail — не смог бы ее найти.
Они бы его не нашли, потому что разработчики из и Enigmail, и GnuPG были в списках рассылки и в Твиттере, утверждая, что никогда не слышали об Efail, и не были уведомлены исследователями. Излишне говорить, что эти обвинения распространялись по Интернету, иногда вместо реальной информации, которая могла бы помочь пользователям (например, были ли исправлены какие-либо проекты).
Само собой разумеется, что ни одно из утверждений не было правдой. На самом деле оба участника проекта вскоре сверились со своими коллегами-разработчиками (и со своими воспоминаниями) и узнали, что они оба были предупреждены исследователями за несколько месяцев и что Enigmail даже разработала патч. (Однако оказалось, что даже этот патч может не полностью решить проблему, и сообщество все еще работает над тем, чтобы выяснить, что именно еще нужно сделать.)
Возможно, это понятная ошибка. Но это, конечно, плохо.
PGP — плохая технология, и она создает плохое сообщество
Теперь, когда я ясно дал понять, что ни исследователи, ни EFF не стремятся заполучить сообщество PGP, позвольте мне надеть маску и рога и рассказать вам, почему кто-то должен быть.
Я много писал о PGP в этом блоге, но в прошлом я писал в основном с технической точки зрения о проблемах с PGP. Но что действительно проблематично в PGP, так это не только криптография; это история о зависимости от пути и о том, как работают сообщества программистов.
Дело в том, что OpenPGP на самом деле не является криптографическим проектом. То есть он не скрепляется криптографией. Он держится на обратной совместимости и (все чаще) своего рода одержимости идеей PGP как самоцелью, а не как средством сделать конечных пользователей более безопасными.
Посмотрим правде в глаза, как протокол, PGP/OpenPGP — это не то, что мы бы разработали, если бы начали сегодня. Он формировался в течение многих лет в основном из экспериментальных частей, которые, в свою очередь, заменялись, перевязывались и ремонтировались, а затем превращались в многочисленные реализации, которые должны были быть безумно гибкими и в то же время совместимыми друг с другом. Результат плохой, и большинство реализующих его программ еще хуже. Это эквивалент всеми любимого старинного спортивного автомобиля, где электрическая система полностью разряжена, но он все еще едет. Вы знаете, такой автомобиль, в котором владелец должен установить ручной переключатель, чтобы он мог вручную включать фонари заднего хода, когда он хочет выехать с парковочного места.
Если PGP исчезнет, то, по моим оценкам, сообществу безопасности потребуется меньше года, чтобы полностью заменить (ключевые части) стандарта чем-то гораздо лучшим и современным. У него будет современная криптография и аутентификация, и, возможно, даже расширения для будущей постквантовой безопасности. Это будет просто . Многие талантливые новые люди будут участвовать в написании неизбежных клиентов и библиотек для Rust, Go и Javascript.
К сожалению для всех нас, (Open)PGP существует. А это значит, что даже новые проекты электронной почты нуждаются в поддержке OpenPGP или, по крайней мере, некоторого его подмножества. Это, в свою очередь, увековечивает миф о PGP и заставляет других клиентов использовать его. И как прямой результат, даже если некоторые клиенты повторно реализуют OpenPGP с нуля, другие клиенты в конечном итоге будут использовать такие инструменты, как GnuPG, которые будут поддерживать шифрование без проверки подлинности с плохими API. И цикл будет идти по кругу, как космический корабль, застрявший у горизонта событий черной дыры.
И поскольку стандарт увековечивает себя, в основном ради того, чтобы быть стандартом, он не сможет привлечь новых специалистов по безопасности. Это оттолкнет именно тех людей, которые должны работать над этими инструментами. Эти люди уйдут и создадут системы шифрования в совершенно другой области, или они займутся криптовалютой. И — с некоторыми исключениями — люди, работающие в сообществе, будут все чаще работать в этом сообществе, потому что они поддерживают PGP, а не потому, что они пытаются найти лучшие технологии безопасности для своих пользователей. И серьезные (электронные) пользователи PGP будут использовать его, потому что им нравится лучше использовать PGP, чем реальный безопасный стандарт электронной почты.
И по мере того, как дела ухудшаются и не развиваются, люди, которые работают над этим, станут более догматичными в отношении его важности, потому что это что-то под угрозой, а не настоящий протокол безопасности, который кто-либо использует. Для меня это то, к чему сегодня движется PGP, и именно поэтому сообществу так трудно мотивировать себя серьезно относиться к этим уязвимостям, и вместо этого оно реагирует оборонительно.
Может быть, это случайный, депрессивный способ закончить пост. Но это история, которую я вижу в OpenPGP. И это меня очень огорчает.
Автор Matthew Greenin Attacks, PGP, Uncategorized 17 мая 2018 г. 17 мая 2018 г.
В общем, я стараюсь ограничивать этот блог сообщениями, посвященными общеприменимым методам криптографии. То есть я не зацикливаюсь на глубоко шатком. Но этот пост будет исключением. Сегодня я собираюсь поговорить о теме, о которой большинство «типичных» разработчиков не задумываются и не должны думать.
В частности: я собираюсь рассказать о различных методах создания схем шифрования с открытым ключом выбранный зашифрованный текст безопасный. Я считаю, что этот пост сэкономил бы мне целую вечность чтения, когда я был аспирантом, поэтому я решил, что не повредит все это записать (хотя это абсолютно не должно служить заменой просто читайте оригинальные документы!)
Предыстория: безопасность CCA(1/2)
Ранние (классические) шифры использовали относительно слабую модель безопасности, если они вообще ее использовали. То есть типичная модель безопасности для схемы шифрования была примерно следующей:
Я создаю ключ шифрования (или пару ключей для шифрования с открытым ключом)
Я даю вам зашифрованное сообщение по моему выбору
Вы «выиграете», если сможете его расшифровать
Очевидно, что в реальном мире эта модель не очень хороша по нескольким причинам. Во-первых, в некоторых случаях злоумышленник много знает о сообщении, которое нужно расшифровать. Например: это может произойти из небольшого пространства (например, из набора игральных карт). По этой причине нам требуется более строгое определение, такое как «семантическая безопасность», которое предполагает, что злоумышленник может выбрать распространение открытого текста, а также может получить шифрование сообщений по своему выбору. Подробнее об этом я писал здесь.
Еще одно ограничение вышеприведенной игры заключается в том, что в некоторых реальных примерах атакующий обладает еще большей силой. То есть: в дополнение к получению шифрования выбранных открытых текстов они могут убедить владельца секретного ключа расшифровать выбранные зашифрованные тексты по своему выбору.
Последняя атака называется атакой выбранного зашифрованного текста (CCA).
На первый взгляд, это действительно глупая модель. Если вы можете попросить владельца ключа расшифровать выбранные зашифрованные тексты, то разве схема явно не нарушена? Вы не можете просто расшифровать все, что хотите?
Ответ, как оказалось, заключается в том, что есть много реальных примеров, когда злоумышленник имеет возможность расшифровки, но схема явно не нарушена. Например:
Иногда злоумышленник может расшифровать ограниченный набор шифротекстов (например, потому что кто-то оставляет дешифровальную машину без присмотра в обеденный перерыв). Тогда возникает вопрос, смогут ли они узнать достаточно от этого доступа, чтобы расшифровать другие зашифрованные тексты, которые генерируются после того, как она теряет доступ к дешифровальной машине — например, сообщения, которые зашифровываются после того, как оператор возвращается с обеда.
Иногда злоумышленник может отправить любой зашифрованный текст, который он хочет, но получит только частичную расшифровку зашифрованного текста. Например, он может узнать только один бит информации, такой как «правильно ли расшифрован этот зашифрованный текст». Тогда возникает вопрос, сможет ли она использовать этот крошечный объем данных, чтобы полностью расшифровать какой-нибудь зашифрованный текст по своему выбору.
Первый пример обычно называют «неадаптивной» атакой с выбранным зашифрованным текстом или атакой CCA1 (и иногда, исторически, атакой «во время обеда»). Есть несколько схем шифрования, которые полностью разваливаются при этой атаке. Самый известный пример из учебника — это схема шифрования с открытым ключом Рабина, которая позволяет восстановить полный секретный ключ всего за одну расшифровку с выбранным зашифрованным текстом.
Более мощный второй пример обычно называют «адаптивной» атакой с выбранным зашифрованным текстом или атакой CCA2. Этот термин относится к идее о том, что злоумышленник может выбирать зашифрованные тексты, которые он пытается расшифровать , основываясь на конкретном зашифрованном тексте, который он хочет атаковать, и увидев ответы на определенные запросы дешифрования.
В этой статье мы будем использовать более мощное «адаптивное» (CCA2) определение, поскольку оно включает в себя определение CCA1. Мы также собираемся сосредоточиться в первую очередь на шифровании с открытым ключом.
Имея это в виду, вот интуитивное определение эксперимента, в котором мы хотим, чтобы схема шифрования с открытым ключом CCA2 могла выжить:
Я создаю пару ключей шифрования для схемы с открытым ключом и даю вам открытый ключ .
Вы можете посылать мне (последовательно и адаптивно) множество зашифрованных текстов, которые я расшифрую своим секретным ключом. Я дам вам результат каждой расшифровки.
В конце концов вы пришлете мне пару сообщений (одинаковой длины), и я выберу случайный бит и верну вам шифрование , которое я обозначу как .
Вы повторите шаг (2), отправив мне зашифрованные тексты для расшифровки. Если вы пришлете мне, я отклоню вашу попытку. Но я расшифрую любой другой зашифрованный текст, который вы мне пришлете, даже если он немного отличается от .
Злоумышленник выводит свое предположение. Они «выиграют» игру, если .
Мы говорим, что наша схема безопасна, если злоумышленник выигрывает только со значительно большей вероятностью, чем если бы он просто угадал наугад. Поскольку они могут выиграть эту игру с вероятностью 1/2, просто угадывая случайным образом, это означает, что мы хотим, чтобы (Вероятность атакующего выиграет игру) – 1/2 была «очень маленькой» (обычно пренебрежимо малой функцией параметра безопасности).
Обратите внимание на две особенности этого определения. Во-первых, он дает злоумышленнику полную расшифровку любого зашифрованного текста, который он мне присылает. Это, очевидно, намного мощнее, чем просто дать злоумышленнику один бит информации, как мы упоминали в примере выше. Но учтите, что мощный — это хороший . Если наша схема сможет оставаться безопасной в этом мощном эксперименте, то очевидно, что она будет безопасной и в условиях, когда злоумышленник получает строго меньше информации с каждым запросом на расшифровку.
Во-вторых, вы должны заметить, что на шаге (4) мы накладываем одно дополнительное условие, а именно то, что злоумышленник не может попросить нас расшифровать . Мы делаем это только для того, чтобы игра не была «тривиальной» — если бы мы не навязывали это требование, злоумышленник всегда мог бы просто сдать нас обратно для расшифровки, и они всегда узнали бы значение .
(Обратите внимание, что мы , а не даем злоумышленнику возможность запрашивать шифрования выбранных открытых текстов. Нам не нужно делать это в версии этой игры с шифрованием с открытым ключом, потому что мы сосредоточены исключительно здесь речь идет о шифровании с открытым ключом — поскольку у злоумышленника есть открытый ключ, он может зашифровать все, что захочет, без моей помощи.)
Отбросив определения, давайте немного поговорим о том, как мы достигаем безопасности CCA2 в реальных схемах.
Небольшой обходной путь: симметричное шифрование
Этот пост в основном будет посвящен шифрованию с открытым ключом, потому что это сложная и интересная для решения проблема. Оказывается, добиться CCA2 для шифрования с симметричным ключом очень просто. Позвольте мне кратко объяснить, почему это так, и почему те же самые идеи не работают для шифрования с открытым ключом.
(Чтобы объяснить это, нам нужно немного изменить приведенное выше определение CCA2, чтобы оно работало в симметричной настройке. Изменения здесь небольшие: мы не будем давать злоумышленнику открытый ключ на шаге (1) и на шагах (2) и (4) мы позволим злоумышленнику запросить шифрование выбранных открытых текстов, а также расшифровку. )
Первое наблюдение состоит в том, что многие распространенные схемы шифрования — в частности, широко используемые режимы шифрования операций, таких как CBC и CTR, — семантически безопасны в модели, в которой злоумышленник не имеет возможности расшифровать выбранные зашифрованные тексты. Однако эти же схемы полностью сломать в модели CCA2.
Простая причина этого — пластичность зашифрованного текста. Возьмем режим CTR, с которым особенно легко запутаться. Допустим, мы получили зашифрованный текст на шаге (4) (напомним, что это шифрование ), его тривиально легко «испортить» зашифрованный текст — просто перевернув, скажем, часть сообщения ( т. е. XOR с ним с «1»). Это дает нам новый зашифрованный текст, который мы теперь можем отправить для расшифровки. Теперь нам разрешено (по правилам игры) представить этот зашифрованный текст и получить , который мы можем использовать для вычисления .
(Связанный, но «реальный» вариант этой атаки — это атака Vaudenay Padding Oracle Attack, которая взламывает реальные реализации криптосистем с симметричным ключом. Вот один, который мы сделали против Apple iMessage. Вот более старый вариант с шифрованием XML.)
Так как же решить эту проблему? Прямое наблюдение заключается в том, что нам нужно предотвратить взлом шифротекста злоумышленником. Общий подход к этому заключается в изменении схемы шифрования таким образом, чтобы она включала тег кода аутентификации сообщения (MAC), вычисляемый для каждого зашифрованного текста в режиме CTR. Ключ для этой схемы MAC генерируется шифрующей стороной (мной) и хранится вместе с ключом шифрования. При запросе на расшифровку зашифрованного текста дешифратор сначала проверяет, действителен ли MAC. Если это не так, процедура расшифровки выведет «ERROR». Предполагая соответствующую схему MAC, злоумышленник не может изменить зашифрованный текст (включая MAC), не вызывая сбоя расшифровки и получения бесполезного результата.
Итак, вкратце: в настройках симметричного шифрования ответ на вопрос безопасности CCA2 заключается в том, чтобы шифрующие стороны просто аутентифицировали каждый зашифрованный текст, используя секретный ключ аутентификации (MAC), который они генерируют. Поскольку мы говорим о симметричном шифровании, этот дополнительный (секретный) ключ аутентификации может быть сгенерирован и сохранен вместе с ключом дешифрования. (В некоторых более эффективных схемах все это работает с единственный ключ , но это просто инженерное удобство.) Все работает отлично.
Итак, теперь мы подошли к главному вопросу.
Защита CCA упрощается при симметричном шифровании. Почему мы не можем сделать то же самое для шифрования с открытым ключом?
Как мы видели выше, оказывается, что надежного шифрования с проверкой подлинности достаточно для обеспечения безопасности CCA(2) в мире симметричного шифрования. К сожалению, когда вы пытаетесь применить ту же идею в общем случае к шифрованию с открытым ключом, она не всегда работает. Для этого есть короткая причина и длинная. Краткая версия: это важно , который выполняет шифрование.
Давайте сосредоточимся на критической разнице. В приведенной выше симметричной игре CCA2 есть только один человек, способный (законно) шифровать зашифрованные тексты. Этот человек я . Проще говоря: человек, который выполняет законные операции шифрования (и имеет секретный ключ), также является тем же человеком, который выполняет дешифрование .
Даже если шифровальщик и расшифровщик буквально не одно и то же лицо, шифровальщик все равно должен быть честный . (Чтобы понять, почему это должно быть так, вспомните, что у шифровальщика есть общий секретный ключ! Если бы эта сторона была плохим парнем, тогда вся схема была бы нарушена, поскольку они могли бы просто выдать секретный ключ плохим парням.) И как только вы сделаете оговорку, что шифровальщик честен, вы почти все сделали. Достаточно просто добавить какую-либо аутентификацию (MAC или подпись) к любому шифротексту, который она шифрует. В этот момент дешифратору нужно только определить, действительно ли какие-либо заданные зашифрованные тексты были получены от (добросовестного) шифровальщика, и избежать расшифровки плохих. Готово.
Шифрование с открытым ключом (PKE) полностью опровергает все эти предположения.
Основная идея схемы шифрования с открытым ключом заключается в том, что любой может зашифровать сообщение для вас, получив копию вашего открытого ключа. Алгоритм шифрования иногда может быть запущен хорошими, честными людьми. Но он также может быть запущен злоумышленниками. Им могут управлять враждебные стороны. Дешифратор должен быть в состоянии справиться со всеми этими случаями. Нельзя просто предположить, что «настоящий» шифровальщик честен.
Позвольте мне привести конкретный пример того, как это может вам навредить. Пару лет назад я написал пост о недостатках Apple iMessage, который (в то время) использовал простую схему шифрования с аутентификацией (открытый ключ). В базовом алгоритме шифрования iMessage использовалось шифрование с открытым ключом (на самом деле это комбинация RSA с некоторым добавлением AES для повышения эффективности), так что любой мог зашифровать сообщение с помощью моего ключа. Для обеспечения подлинности требовалось, чтобы каждое сообщение было подписано отправителем с помощью подписи ECDSA.
Когда я получал сообщение, я искал открытый ключ отправителя и сначала проверял, действительна ли подпись. Это помешает плохим парням подделывать сообщение в полете — например, , выполняет неприятные вещи, такие как адаптивные атаки с выбранным шифротекстом. Если немного прищуриться, это почти в точности прямой перевод симметричного криптографического подхода, который мы обсуждали выше. Мы просто меняем MAC на цифровую подпись.
Проблемы с этой схемой становятся очевидными, если учесть, что зашифрованные тексты могут присылать мне несколько человек. Допустим, противник находится на пути связи и перехватывает подписанное сообщение от вас ко мне. Они хотят измениться ( т. е. растерзать) сообщение, чтобы они могли выполнить какую-то хитрую атаку. Что ж, оказывается, это просто. Они просто срывают честную подпись и заменяют ее собственной:

Новое сообщение идентично, но теперь кажется, что оно исходит от другого человека (злоумышленника). Поскольку у злоумышленника есть собственный ключ подписи, он может изменять зашифрованное сообщение сколько угодно и подписывать новые версии этого сообщения. Если вы подключите эту атаку к (варианту) игры CCA2 с открытым ключом, вы увидите, что они довольно легко выиграют. Все, что им нужно сделать, это изменить зашифрованный текст запроса на шаге (4), чтобы он был подписан их собственным ключом подписи, затем они могут изменить его, обманув шифрованием в режиме CTR, и запросить расшифровку этого зашифрованного текста.
Конечно, если я только принимаю сообщения, подписанные каким-то первоначальным (честным) отправителем, эта схема может работать нормально. Но не в этом суть шифрования с открытым ключом. В реальной схеме с открытым ключом — подобной той, которую пыталась создать Apple iMessage, — я должен иметь возможность (безопасно) расшифровывать сообщения от любого , и в таких условиях эта наивная схема довольно сильно ломается.
Фух.
Хорошо, этот пост получился немного длинным, и до сих пор я фактически не добрался до различных «трюков» для добавления выбранной защиты зашифрованного текста к реальным схемам шифрования с открытым ключом. Придется подождать до следующего поста, который скоро появится.
Щелкните здесь, чтобы перейти к части 2.
Автор: Мэтью Гринин Без рубрики 21 апреля 2018 г. 20 июля 2018 г.
За последние несколько лет мне посчастливилось наблюдать две противоречивые и увлекательные тенденции. Во-первых, мы, , наконец, начинаем использовать криптографию, которую исследователи разрабатывали последние сорок лет. Мы видим это каждый день на примерах, начиная от зашифрованных сообщений и заканчивая безопасностью телефона и криптовалютами.
Вторая тенденция заключается в том, что криптографы готовятся к тому, что все эти хорошие времена закончатся.
Но прежде чем я перейду ко всему этому — намного ниже — позвольте мне подчеркнуть, что это , а не пост об апокалипсисе квантовых вычислений и не об успехе криптографии в 21 веке. Вместо этого я собираюсь поговорить о чем-то гораздо более странном. Этот пост будет посвящен одной из самых простых (и самых крутых!) криптографических технологий, когда-либо разработанных: подписям на основе хэшей.
Схемы подписи на основе хэша были впервые изобретены в конце 1970-х годов Лесли Лэмпортом и значительно улучшены Ральфом Мерклом и другими. В течение многих лет их в основном рассматривали как интересное криптографическое захолустье, главным образом потому, что они производят относительно большие подписи (помимо других сложностей). Однако в последние годы эти конструкции пережили своего рода ренессанс, в основном потому, что — в отличие от подписей, основанных на RSA или допущении дискретного логарифма — они в основном считаются устойчивыми к серьезным квантовым атакам, таким как алгоритм Шора.
Сначала предыстория.
Предыстория: хэш-функции и схемы подписи
Чтобы понимать хэш-подписи, важно иметь некоторое представление о криптографических хеш-функциях. Эти функции принимают некоторую входную строку (обычно или произвольной длины) и выдают «дайджест» фиксированного размера на выходе. Обычные криптографические хэш-функции, такие как SHA2, SHA3 или Blake2, производят дайджесты длиной от 256 до 512 бит.
Чтобы функция считалась «криптографическим» хешем, она должна соответствовать определенным требованиям безопасности. Их много, но здесь мы сосредоточимся только на трех наиболее распространенных:
1. Сопротивление предварительному изображению (иногда известное как «односторонность»): при наличии некоторого выхода , должно быть много времени, чтобы найти такой вход, что . (Конечно, к этому есть много предостережений, но в идеале наилучшая такая атака должна требовать времени, сравнимого с полным перебором любого распределения, из которого оно взято.)
2. Сопротивление второму прообразу: это тонко отличается от сопротивления предварительного изображения. Злоумышленнику будет сложно найти различных входных данных, таких что .
3. Устойчивость к столкновениям: должно быть трудно найти любых два значения, для которых . Обратите внимание, что это гораздо более сильное предположение, чем сопротивление второму прообразу, поскольку злоумышленник имеет полную свободу найти любые два сообщения по своему выбору.
Примеры хэш-функций, которые я упомянул выше, , как полагают, обеспечивают все эти свойства. То есть никто не сформулировал содержательную (или даже концептуальную) атаку, которая ломает любой из них. Конечно, это всегда может измениться, и в этом случае мы почти наверняка перестанем их использовать. (Мы обсудим частный случай квантовых атак чуть ниже.)
Поскольку наша цель — использовать хеш-функции для построения схем подписи, полезно также кратко рассмотреть этот примитив.
Схема цифровой подписи представляет собой примитив открытого ключа, в котором пользователь (или «подписавшийся») создает пару ключей , называемую открытым ключом и закрытым ключом. Пользователь сохраняет закрытый ключ и может использовать его для «подписания» произвольных сообщений, создавая результирующую цифровую подпись. Любой, у кого есть открытый ключ, может проверить правильность сообщения и связанной с ним подписи.
С точки зрения безопасности, главное свойство, которое мы хотим получить от схемы подписи, — это не подделка, или « экзистенциальная не подделка ». Это требование означает, что злоумышленник (кто-то, у кого нет закрытого ключа) не должен иметь возможности подделать действительную подпись в сообщении, которое вы не подписывали. Дополнительные сведения о формальных определениях безопасности подписи см. на этой странице.
Одноразовая подпись Лампорта
Первые схемы подписи на основе хэша были изобретены в 1979 математика по имени Лесли Лэмпорт. Лэмпорт заметил, что имея только простую хеш-функцию — или, точнее, одностороннюю функцию — можно построить чрезвычайно мощную схему подписи.
Мощно при условии, что вам нужно подписать только одно сообщение! Подробнее об этом ниже.
Для целей данного обсуждения предположим, что у нас есть следующий ингредиент: хэш-функция, которая принимает, скажем, 256-битные входные данные и производит 256-битные выходные данные. SHA256 был бы прекрасным примером такой функции. Нам также понадобится способ генерировать случайные биты.
Давайте представим, что наша цель — подписать 256-битные сообщения. Чтобы сгенерировать наш секретный ключ, первое, что нам нужно сделать, это сгенерировать серию из 512 отдельных случайных битовых строк, каждая из которых имеет длину 256 бит. Для удобства мы организуем эти строки в два отдельных списка и будем ссылаться на каждый из них по следующему индексу:

Списки представляют собой секретный ключ , который мы будем использовать для подписи. Чтобы сгенерировать открытый ключ, мы теперь просто хэш каждая из этих случайных строк, использующих нашу функцию . В результате получается вторая пара списков:

Теперь мы можем раздать наш открытый ключ всему миру. Например, мы можем отправить его нашим друзьям, встроить в сертификат или опубликовать на Keybase.
Теперь предположим, что мы хотим подписать 256-битное сообщение, используя наш секретный ключ. Самое первое, что мы делаем, это разбиваем и представляем в виде последовательности из 256 отдельных битов:
Остальная часть алгоритма подписи ослепительно проста. Мы просто прорабатываем сообщение от первого до последнего бита и выбираем строку из один из списка двух секретных ключей. Список, который мы выбираем, зависит от значения бита сообщения, которое мы пытаемся подписать.
Конкретно, для i=1 до 256: если бит сообщения , мы получаем строку секретного ключа из списка и выводим эту строку как часть нашей подписи. Если сообщение битовое, копируем соответствующую строку из списка. Сделав это для каждого из битов сообщения, мы объединяем все выбранные нами строки. Это формирует нашу подпись.
Вот игрушечная иллюстрация процесса, где (для простоты) секретный ключ и сообщение имеют длину всего восемь бит. Обратите внимание, что каждый цветной прямоугольник ниже представляет различных 256-битная случайная строка:
Когда пользователь, у которого уже есть открытый ключ, получает сообщение и подпись, он может легко проверить подпись. Пусть представляет компонент подписи: для каждой такой строки. Она просто проверяет соответствующий бит сообщения и вычисляет хэш. Если результат должен соответствовать соответствующему элементу из . Если результат должен соответствовать элементу в .
Подпись действительна, если каждый одиночный элемент подписи при хэшировании соответствует правильной части открытого ключа. Вот (по общему признанию) схематичная иллюстрация процесса проверки, по крайней мере, для одного компонента подписи:
Если ваше первоначальное впечатление о замысле Лэмпорта сводится к безумию, вы одновременно и правы, и немного неправы.
Начнем с негатива. Во-первых, легко заметить, что подписи и ключи Лампорта довольно велики: порядка тысячи битов. Более того — и, что гораздо важнее, — у этой схемы есть серьезное ограничение безопасности: каждый ключ может использоваться только для подписи одного сообщения . Это делает схему Лэмпорта примером того, что называется «одноразовым размером».
Чтобы понять, почему существует это ограничение, вспомните, что каждая подпись Лампорта раскрывает ровно одно из двух возможных значений секретного ключа в каждой позиции. Если я подпишу только одно сообщение, схема подписи работает хорошо. Однако, если я когда-нибудь подпишу два сообщения , которые различаются в любой битовой позиции , то в конечном итоге я передам оба значения секретного ключа для этой позиции. Это может быть проблемой.
Представьте, что злоумышленник видит две действительные подписи на разных сообщениях. Она может быть в состоянии выполнить простое « Mix and Match » атака подделки, которая позволяет ей подписать третье сообщение, которое я на самом деле никогда не подписывал. Вот как это может выглядеть в нашем игрушечном примере:
Степень, в которой это причиняет вам боль, зависит от того, насколько различны сообщения и сколько из них вы дали злоумышленнику для игры. Но это редко хорошие новости.
Итак, подытожим наши наблюдения о схеме подписи Лэмпорта. Это просто. Это быстро. И все же для различных практических причин, по которым это отстой. Может быть, мы можем сделать немного лучше.
От одноразовых до многократных подписей: древовидная подпись Меркла
Хотя схема Лампорта является хорошим началом, наша неспособность подписать множество сообщений с помощью одного ключа является огромным недостатком. Никто не был вдохновлен этим больше, чем Ральф Меркл, ученик Мартина Хеллмана. Он быстро придумал умный способ решить эту проблему.
Хотя мы не можем точно повторить шаги Меркла, давайте посмотрим, сможем ли мы восстановить некоторые из очевидных идей.
Допустим, наша цель — использовать подпись Лэмпорта для подписи множества сообщений — скажем, из них. Самый очевидный подход — просто сгенерировать разные пары ключей для исходной схемы Лампорта, а затем объединить все открытые ключи в один мегаключ.
(Мега-ключ — это технический термин, который я только что придумал).
Если подписывающая сторона владеет всеми компонентами секретного ключа, теперь она может подписывать разные сообщения, используя ровно один секретный ключ Лампорта для каждого сообщения. Кажется, это решает проблему, не требуя от нее повторного использования секретного ключа. Верификатор имеет все открытые ключи и может проверить все полученные сообщения. Ключи Лэмпорта никогда не используются для подписи дважды.
Очевидно, что такой подход отстой.
В частности, в этом наивном подходе время подписания требует, чтобы подписывающая сторона распространяла открытый ключ, который в раз больше, чем обычный открытый ключ Лампорта. (Ей также нужно будет хранить такую же кучу секретных ключей.) В какой-то момент людям это надоест, и, вероятно, не все станут очень большими. Входит Меркл.
Меркл предложил способ сохранить возможность подписывать разные сообщения, но без — увеличение открытых ключей с линейной стоимостью. Идея Меркла работала так:
Сначала сгенерируйте отдельные пары ключей Лампорта. Мы можем назвать тех.
Затем поместите каждый открытый ключ на один лист хеш-дерева Меркла (см. ниже) и вычислите корень дерева. Этот корень станет «главным» открытым ключом новой схемы подписи Merkle.
Подписавший сохраняет все открытые и секретные ключи Лампорта для использования при подписании.
Здесь описаны деревья Меркла. Грубо говоря, они предоставляют способ собрать множество различных значений, чтобы их можно было представить одним «корневым» хэшем (длиной 256 бит, с использованием хеш-функции в нашем примере). Имея этот хэш, можно создать простое «доказательство» того, что элемент находится в данном хеш-дереве. Более того, это доказательство имеет размер логарифмическое в количестве листьев на дереве.
Дерево Меркла, иллюстрация из Википедии. Открытые ключи Лампорта находятся в листьях этого дерева, а корень становится основным открытым ключом.
Чтобы подписать сообщение, подписывающая сторона просто выбирает открытый ключ из дерева и подписывает сообщение, используя соответствующий секретный ключ Лампорта. Затем она объединяет полученную подпись с открытым ключом Лампорта и прикрепляет «доказательство Меркла», показывающее, что этот конкретный открытый ключ Лампорта содержится в дереве, идентифицируемом корнем (9).1218 т. е. открытый ключ всей схемы). Затем она передает всю эту коллекцию в качестве подписи сообщения.
(Чтобы проверить подпись этой формы, верификатор просто распаковывает эту «подпись» как подпись Лампорта, открытый ключ Лампорта и доказательство Меркла. Она сверяет подпись Лампорта с данным открытым ключом Лампорта и использует доказательство Меркла для убедиться, что открытый ключ Лэмпорта действительно находится в дереве. После достижения этих трех целей она может доверять подписи как действительной.)
Недостатком этого подхода является увеличение размера «подписи» более чем в два раза. Однако главный открытый ключ для схемы теперь представляет собой всего лишь одно хеш-значение, что делает масштабирование этого подхода более четким, чем наивное решение, описанное выше.
В качестве окончательной оптимизации данные секретного ключа сами по себе могут быть «сжаты» путем генерации всех различных секретных ключей с использованием выходных данных криптографического генератора псевдослучайных чисел, что позволяет генерировать огромное количество (очевидно, случайных) битов из одного короткого «семени».
Вот это да.
Повышение эффективности подписей и ключей (немного)
Подход Меркла позволяет преобразовать любую одноразовую подпись в временную подпись. Тем не менее, его конструкция по-прежнему требует от нас использования некоторой базовой одноразовой подписи, такой как схема Лэмпорта. К сожалению, затраты на пропускную способность схемы Лэмпорта все еще относительно высоки.
Есть две основные оптимизации, которые могут помочь снизить эти расходы. Первый также был предложен Меркле. Сначала мы рассмотрим эту простую технику, главным образом потому, что она помогает объяснить более мощный подход.
Если вы помните схему Лэмпорта, то для того, чтобы подписать 256-битное сообщение, нам требовался вектор, состоящий из 512 отдельных строк секретного ключа (и открытого ключа). Сама подпись представляла собой набор из 256 секретных битовых строк. (Эти числа были мотивированы тем фактом, что каждый бит сообщения, которое должно быть подписано, может быть либо «0», либо «1», и, таким образом, соответствующий элемент секретного ключа должен быть извлечен из одного из двух разных списков секретных ключей. .)
Но вот мысль: а что если мы не подписывают все биты сообщения ?
Давайте будем немного яснее. В схеме Лампорта мы подписываем каждый бит сообщения — независимо от его значения — выводом одной секретной строки. Что, если вместо того, чтобы подписывать в сообщении нулевых значений и единиц значений, мы подписывали только биты сообщения, равные единице ? Это сократит размер открытого и секретного ключа вдвое, поскольку мы сможем полностью избавиться от списка.
Теперь у нас будет только одиночный список битовых строк в нашем секретном ключе. Для каждой битовой позиции сообщения, где мы будем выводить строку . Для каждой позиции, где мы будем выводить… zilch . (Это также привело бы к уменьшению размера подписи, поскольку многие сообщения содержат кучу нулевых битов, и теперь это ничего нам не будет стоить!)
Очевидная проблема с этим подходом заключается в том, что он ужасно небезопасен. Пожалуйста, не реализуйте эту схему!
В качестве примера предположим, что злоумышленник наблюдает (подписанное) сообщение, которое начинается с «1111…», и он хочет отредактировать сообщение, чтобы оно читалось как «0000…» — без нарушения подписи. Все, что ей нужно сделать, это удалить несколько компонентов подписи! Короче говоря, хотя очень сложно «перевернуть» нулевой бит в один бит, сделать обратное катастрофически легко.
А оказывается есть исправление, и довольно изящное.
Видите ли, хотя мы не можем помешать злоумышленнику отредактировать наше сообщение, превратив один бит в ноль бит, мы можем перехватить их . Для этого мы добавляем к сообщению простую «контрольную сумму», , затем подпишите комбинацию исходного сообщения и контрольной суммы. Проверщик подписи должен проверить всю подпись по обоим значениям, а также и убедиться, что полученная контрольная сумма верна.
Используемая нами контрольная сумма тривиальна: она состоит из простого двоичного целого числа, которое представляет общее число нулевых битов в исходном сообщении.
Если злоумышленник попытается изменить содержимое сообщения (за исключением контрольной суммы), чтобы превратить какой-то один бит в нулевой бит, схема подписи ее не остановит. Но эта атака имеет эффект увеличения количество нулевых битов в сообщении . Это немедленно сделает контрольную сумму недействительной, и верификатор отклонит подпись.
Конечно, хитрый злоумышленник может также попытаться изменить контрольную сумму (которая также подписана вместе с сообщением), чтобы «подправить» ее, увеличив целочисленное значение контрольной суммы. Однако — и это очень важно — поскольку контрольная сумма представляет собой двоичное целое число, для того, чтобы увеличить значение контрольной суммы, ей всегда нужно было бы преобразовать какой-то нулевой бит контрольная сумма в один бит. Но так как контрольная сумма также подписана , а схема подписи предотвращает такого рода изменения, злоумышленнику некуда деваться.
(Если вы ведете учет дома, это несколько увеличивает размер подписываемого «сообщения». В нашем примере с 256-битным сообщением для контрольной суммы потребуются дополнительные восемь бит и соответствующая стоимость подписи. Однако, если в сообщении много нулевых битов, уменьшенный размер подписи, как правило, все равно будет выигрышным.)
Winternitz: обмен места на время
Приведенный выше трюк уменьшает размер открытого ключа вдвое и уменьшает размер (некоторых) подписей на аналогичную величину. Это красиво, но не совсем революционно. Он по-прежнему дает ключи и подписи длиной в тысячи битов.
Было бы неплохо, если бы мы смогли увеличить эти цифры.
Последняя оптимизация, о которой мы поговорим, была предложена Робертом Винтерницем как дальнейшая оптимизация описанной выше техники Меркла. На практике это дает 4-8-кратное сокращение размера подписей и открытых ключей — за счет увеличения времени как подписи, так и проверки.
Идея Винтерница является примером метода, называемого «компромисс времени и пространства». Этот термин относится к классу решений, в которых пространство уменьшается за счет увеличения времени вычислений (или наоборот). Чтобы объяснить подход Винтерница, полезно задать следующий вопрос:
Что, если вместо того, чтобы подписывать сообщения, состоящие из битов (0 или 1), мы относимся к нашим сообщениям так, как если бы они были закодированы с использованием более крупных алфавитов символов? Например, что, если мы подпишем четырехбитные «кусочки»? Или восьмибитные байты?
В исходной схеме Лэмпорта у нас было два списка битовых строк как часть подписывающего (и открытого) ключа. Один предназначался для подписи нулевых бит сообщения, а другой — для один бит.
Теперь предположим, что мы хотим подписать байт , а не биты. Очевидной идеей было бы увеличить количество списков секретных ключей (и открытых ключей) с двух таких списков до 256 таких списков — по одному списку на каждое возможное значение байта сообщения. Подписавшийся может работать с сообщением один байт за раз и выбирать из гораздо большего меню значений ключей.
К сожалению, это решение действительно вонючее. Это уменьшает размер подписи в восемь раз за счет увеличения размера открытого и секретного ключа в 256 раз. Даже это может быть хорошо, если открытые ключи можно использовать для многих подписей, но они не могут — когда дело доходит до повторного использования ключей, эта «версия Lamport для подписи байтов» страдает теми же ограничениями, что и оригинальная подпись Lamport.
Все это подводит нас к идее Винтерница.
Так как слишком дорого хранить и распространять 256 действительно случайных списков, что, если мы создадим эти списки программно только тогда, когда они нам понадобятся?
Идея Винтерница заключалась в том, чтобы сгенерировать единый список случайных начальных чисел для нашего исходного секретного ключа. Вместо случайного создания дополнительных списков он предложил использовать хеш-функцию для каждого элемента этого исходного секретного ключа, чтобы получить следующих такой список для секретного ключа: . Точно так же можно снова использовать хэш-функцию в этом списке, чтобы получить следующий список. И так далее для многих возможных списков.
Это полезно тем, что теперь нам нужно хранить только один список значений секретного ключа, а все остальные списки мы можем получить по запросу, просто применив хеш-функцию.
А как же открытый ключ? Здесь Винтерниц становится умнее.
В частности, Винтерниц предположил, что открытый ключ можно получить, еще раз применив хеш-функцию к окончательному списку секретных ключей. Это создаст единый список открытых ключей. (На практике нам нужно только 255 списков секретных ключей, поскольку мы можем рассматривать окончательный список секретных ключей как открытый ключ.) Элегантность этого подхода заключается в том, что при наличии любого из возможных значений секретного ключа всегда можно проверить его на соответствие открытому ключу, просто многократно хешируя вперед и проверяя, достигаем ли мы элемента открытого ключа.
Весь процесс генерации ключей показан ниже:
Обратите внимание, что для «подписания» байтов нам нужно только 255 списков секретных ключей, а не 256 из них. Окончательный секретный список эквивалентен открытому ключу.
Чтобы подписать первый байт сообщения, мы должны выбрать значение из соответствующего списка. Например, если бы байт сообщения был «0», мы бы вывели значение из в нашей подписи. Если бы байт сообщения был «20», мы бы вывели значение из . Для байтов с максимальным значением «255» у нас нет списка секретных ключей. Ничего страшного: в этом случае мы можем вывести пустую строку или соответствующий элемент .
Также обратите внимание, что на практике нам не нужно хранить каждый из этих списков секретных ключей. Мы можем получить любое значение секретного ключа по запросу , имея только исходный список. Верификатор содержит только вектор открытого ключа и (как упоминалось выше) просто хеширует вперед соответствующее количество раз — в зависимости от байта сообщения — чтобы увидеть, равен ли результат соответствующему компоненту открытого ключа.
Как и обсуждение оптимизации Merkle в предыдущем разделе, представленная схема имеет вопиющую уязвимость. Поскольку секретные ключи связаны ( , т. е. ), любой, кто увидит сообщение, подписанное как «0», может легко изменить соответствующий байт сообщения на «1» и обновить подпись, чтобы она соответствовала. На самом деле злоумышленник может увеличить значение любого байта (байтов) в сообщении. Без какой-либо проверки этой возможности это позволило бы проводить очень мощные атаки с подделкой.
Решение этой проблемы похоже на то, что мы обсуждали чуть выше. Чтобы предотвратить изменение подписи злоумышленником, подписывающая сторона вычисляет и также подписывает контрольная сумма байт исходного сообщения. Структура этой контрольной суммы предназначена для предотвращения увеличения злоумышленником любого из байтов без аннулирования контрольной суммы. Я не буду сейчас вдаваться в кровавые подробности, но вы можете найти их здесь.
Само собой разумеется, что правильное получение контрольной суммы имеет решающее значение. Облажаешься хоть чуть-чуть, и с тобой могут случиться очень плохие вещи. Это было бы особенно неприятно, если бы вы развернули эти подписи в производственной системе.
Проиллюстрированный на одной жуткой картинке 4-байтовый игрушечный пример схемы Винтерница выглядит так:
Обратите внимание, что Сообщение в данном случае состоит из байтов , а не битов. Я почти уверен, что вычислил контрольную сумму правильно, но я сделал это вручную, и это не всегда получается так хорошо.
Для чего нужны подписи на основе хэшей?
На протяжении всего обсуждения мы в основном говорили о как хэш-подписей, а не о почему из них. Пришло время заняться этим. В чем смысл этих странных конструкций?
Одним из первых аргументов в пользу подписей на основе хэшей является то, что они удивительно быстрые и простые. Поскольку они требуют только оценки хеш-функции и некоторого копирования данных, с точки зрения чисто вычислительных затрат, они весьма конкурентоспособны с такими схемами, как ECDSA и RSA. Гипотетически это может быть важно для легких устройств. Конечно, эта эффективность достигается за счет огромного компромисса в эффективности полосы пропускания.
Однако существует более сложная причина (недавнего) всплеска внимания к конструкциям подписи на основе хэшей. Это связано с тем, что вся наша криптография с открытым ключом вот-вот будет взломана.
Более конкретно: неизбежное появление квантовых компьютеров окажет огромное влияние на безопасность почти всех наших практических схем подписи, от RSA до ECDSA и так далее. Это связано с тем, что алгоритм Шора (и его многочисленные варианты) дает нам полиномиальный алгоритм для решения задач дискретного логарифмирования и факторизации, который, вероятно, сделает большинство этих схем небезопасными.
Большинство реализаций подписей на основе хэшей не уязвимы для алгоритма Шора. Это, конечно, не означает, что они полностью невосприимчивы к квантовым компьютерам. Лучшие общие квантовые атаки на хеш-функции основаны на методе поиска, называемом алгоритмом Гровера, который снижает эффективную безопасность хеш-функции. Однако снижение эффективной безопасности далеко не так сильно, как у алгоритма Шора (он находится в диапазоне от квадратного до кубического корня), поэтому безопасность можно сохранить, просто увеличив внутреннюю емкость и размер вывода хеш-функции. Хэш-функции, такие как SHA3, были специально разработаны с большими размерами дайджеста, чтобы обеспечить устойчивость к таким атакам.
Так что, по крайней мере теоретически, подписи на основе хеша интересны, потому что они обеспечивают нам линию защиты от будущих квантовых компьютеров — во всяком случае, на данный момент.
Что насчет будущего?
Обратите внимание, что до сих пор я обсуждал только некоторые из «классических» схем подписи на основе хэшей. Все схемы, которые я описал выше, были разработаны в 1970-х или начале 1980-х годов. Это едва ли подводит нас к сегодняшнему дню.
После того, как я написал первоначальный вариант этой статьи, несколько человек попросили рассказать о последних разработках в этой области. Я не могу привести здесь исчерпывающий список, но позвольте мне описать лишь пару более свежих идей, которые выдвинули другие (спасибо Зуко и Клаудио Орланди):
Подписи без состояния. Ограничение всех описанных выше схем подписи заключается в том, что они требуют, чтобы подписывающая сторона сохраняла состояние между подписями . В случае одноразовых подписей рассуждение очевидно: вы должны избегать использования любого ключа более одного раза. Но даже в многоразовой подписи Меркла вы должны помнить, какой лист открытого ключа вы используете, чтобы избежать повторного использования любого листа. Хуже того, схема Меркла требует, чтобы подписывающая сторона построила все пары ключей впереди, поэтому общее количество подписей ограничено.
В 1980-х годах Одед Гольдрейх указал, что можно создавать подписи без этих ограничений. Идея заключается в следующем: вместо того, чтобы заранее генерировать все подписи, можно сгенерировать короткое «дерево сертификации» из одноразовых открытых ключей. Каждый из этих ключей можно использовать для подписи дополнительных одноразовых открытых ключей на нижнем уровне дерева и т. д. и т. п. При условии, что все закрытые ключи генерируются детерминистически с использованием одного начального числа, это означает, что полное дерево не обязательно должно существовать полностью во время генерации ключа, но может быть построено по требованию всякий раз, когда генерируется новый ключ. Каждая подпись содержит «цепочку сертификатов» из подписей и открытых ключей, начиная с корня и заканчивая настоящей парой ключей подписи в нижней части дерева.
Этот метод позволяет строить чрезвычайно «глубокие» деревья с огромным (экспоненциальным) числом возможных ключей подписи. Это позволяет нам сконструировать столько одноразовых открытых ключей, что если мы выберем ключ подписи случайным образом (или псевдослучайно), то с высокой вероятностью одна и та же подпись никогда не будет использована дважды. Это интуиция, конечно. Высокооптимизированное и конкретное воплощение этой идеи см. в предложении SPHINCS от Bernstein et al. Конкретный экземпляр SPHINCS-256 дает подписи размером примерно 41 КБ.
Пикник: постквантовые сигнатуры с нулевым разглашением. Совсем в другом направлении лежит Пикник. Picnic основан на новой неинтерактивной системе доказательства с нулевым разглашением под названием ZKBoo. ZKBoo — это новая система доказательства ZK, которая работает на основе метода, называемого «MPC в голове», когда доказывающий использует многосторонние вычисления для вычисления функции с самим доказывающим. Это слишком сложно для подробного объяснения, но конечный результат состоит в том, что можно доказать сложные утверждения, используя только хеш-функции.
Короче говоря, Picnic и аналогичные системы проверки ZK обеспечивают второе направление для создания подписей из хеш-функций. Стоимость этих подписей пока достаточно велика — сотни килобайт. Но будущие усовершенствования техники могут существенно уменьшить этот размер.
Эпилог: скучные детали безопасности
Если вы помните чуть раньше в этой статье, я потратил некоторое время на описание свойств безопасности хеш-функций. Это было не только для шоу. Видите ли, безопасность подписи на основе хэша сильно зависит от того, какие свойства может предоставить хэш-функция.
(И косвенно, ненадежность подписи на основе хэша зависит от того, какие свойства хеш-функции удалось взломать злоумышленнику.)
прообраз-сопротивление хеш-функции. Интуитивно это кажется довольно простым. Возьмем в качестве примера подпись Лэмпорта. Имея элемент открытого ключа, злоумышленник, способный вычислить прообразы хэшей, может легко восстановить действительный секретный ключ для этого компонента подписи. Эта атака, очевидно, делает схему небезопасной.
Однако этот аргумент рассматривает только случай, когда злоумышленник имеет открытый ключ , но еще не видел действительной подписи. В этом случае злоумышленник имеет немного больше информации. Теперь у них есть (например) как открытый ключ, так и часть секретного ключа: и . Если такой злоумышленник сможет найти секундный прообраз для открытого ключа, он не сможет подписать другое сообщение. Но она поставила новую подпись . В строгом определении безопасности подписи (SUF-CMA) это действительно считается допустимой атакой. Таким образом, SUF-CMA требует несколько более сильного свойства сопротивления второму прообразу.
Конечно, есть еще одна проблема, которая возникает при большинстве практических применений схем подписи на основе хэшей. Вы заметите, что в приведенном выше описании предполагается, что мы подписываем 256-битные сообщения. Проблема в том, что в реальных приложениях многие сообщения имеют длину более 256 бит. Как следствие, большинство людей используют хеш-функцию, чтобы сначала хешировать сообщение как, а затем подписывать полученное значение вместо сообщения.
Это приводит к окончательной атаке на результирующую схему подписи, поскольку экзистенциальная невозможность подделки схемы теперь зависит от сопротивление столкновению хеш-функции. Злоумышленник, который может найти два разных сообщения, например, нашел действительную подпись в двух разных сообщениях. Это приводит к тривиальному нарушению безопасности EUF-CMA.
Автор: Мэтью Гринин Без рубрики 7 апреля 2018 г. 18 апреля 2018 г.
Вчера Дэвид Бенджамин опубликовал довольно эзотерическую заметку в списке рассылки TLS IETF. На поверхностном уровне в посте описываются некоторые вызывающие припадки скучные недостатки старых принтеров Canon. Для большинства людей это был полный сон. Однако для меня и некоторых моих коллег это было похоже на ту сцену в Секретных материалах, где Малдер и Скалли наконец узнают, что инопланетяне реальны.
Эти окаменевшие принтеры подтвердили теорию, которую мы разработали в 2014 году, но не смогли доказать, а именно существование особой функции в библиотеке RSA BSAFE TLS под названием «Расширенный случайный выбор», которую мы считаем свидетельством согласованные усилия АНБ по лазейке в криптографическую технологию США.
Прежде чем я перейду к деталям, я хочу предостеречь этот пост двумя разными способами. Во-первых, я слишком много писал на тему криптографических бэкдоров. В 2013 году разоблачения Сноудена выявили существование кампании по саботажу систем шифрования США. С тех пор криптографы потратили тысячи часов на выявление, документирование и попытки убедить людей заботиться об этих бэкдорах. Мы устали и хотим заняться более полезными делами.
Второе предостережение касается проблемы с любым обсуждением криптографических лазеек. В частности, вы никогда не получите абсолютного доказательства . Всегда есть какое-то невинное или случайное объяснение, которое могло бы соответствовать уликам — , может быть, все это было глупой ошибкой . Поэтому вы ищете модели маловероятных совпадений и часто пользуетесь бритвой Оккама. Вы не получаете Сноудена каждый день.
После всего сказанного давайте поговорим о расширенном рандоме и о том, что это говорит нам об АНБ. Сначала немного предыстории.
Dual_EC_DRBG и RSA BSAFE
Чтобы понять контекст этого открытия, вам необходимо знать о стандарте под названием Dual EC DRBG. Это был предложенный генератор случайных чисел, разработанный АНБ в начале 2000-х годов. Он был стандартизирован NIST в 2007 году, а позже развернут в некоторых важных криптографических продуктах, хотя в то время мы об этом не знали.
У Dual EC есть серьезная проблема, заключающаяся в том, что он, вероятно, содержит лазейку. На это указывали в 2007 году Шумоу и Фергюсон, а в 2013 году они фактически подтвердились утечками Сноудена. Последовала драма. В ответ NIST отозвал стандарт. (Объяснение бэкдора Dual EC см. здесь.)
Примерно в это же время мир узнал, что RSA Security сделала Dual EC генератором случайных чисел по умолчанию в своей популярной криптографической библиотеке, которая называлась BSAFE. RSA не то чтобы держала это в секрете, но это был такой безумный поступок, о котором никто (в криптографическом сообществе) не знал. Так что в течение многих лет RSA поставляла свою библиотеку с этим сумасшедшим алгоритмом, который использовался во всех видах коммерческих устройств.
Однако драма RSA на этом не закончилась. В конце 2013 года агентство Reuters сообщило, что RSA потребовала 10 миллионов долларов США для создания бэкдора в своем программном обеспечении. RSA как бы это отрицает. Или что-то. Это не совсем понятно.
Независимо от намерения, известно, что RSA BSAFE действительно включала Dual EC. Конечно, это могло быть невинным решением, поскольку Dual EC был стандартом NIST. Чтобы пролить свет на этот вопрос, в 2014 году мы с коллегами решили перепроектировать библиотеку BSAFE, чтобы проверить, действительно ли предполагаемый бэкдор в Dual EC может быть использован злоумышленником, например АНБ. Мы посчитали, что определенные инженерные решения, принятые проектировщиками библиотек, могут быть информативными и склонить чашу весов в ту или иную сторону.
Оказывается, были.
Extended Random
В ходе обратного проектирования Java-версии BSAFE мы обнаружили забавное включение. В частности, мы обнаружили, что BSAFE поддерживает нестандартное расширение протокола TLS под названием «Extended Random».
Расширенное случайное расширение — это проект IETF, предложенный сотрудником АНБ по имени Маргарет Солтер (в какой-то момент глава Управления обеспечения безопасности информации АНБ, которое работало над «защитной» криптографией для Министерства обороны США) вместе с Эриком Рескорлой в качестве подрядчика. (Эрика явно наняли для разработки достойного предложения, которое не повредит TLS и в первую очередь будет использоваться на правительственных машинах. АНБ не поделилось с ним своими мотивами.)
Важно отметить, что расширенный случайный выбор сам по себе не создает никаких криптографических уязвимостей. Все, что он делает, — это увеличивает количество случайных данных («одноразовые номера»), используемых в соединении по протоколу TLS. Это никак не повредит TLS, и, помимо , он в основном предназначался для машин правительства США.
Единственное, что интересно в расширенном рандоме, это то, что происходит , когда эти случайные данные генерируются с использованием алгоритма Dual EC. В частности, эти дополнительные данные действуют как «ракетное топливо», значительно повышая эффективность использования бэкдора Dual EC для расшифровки TLS-соединений.
Короче говоря, если вы являетесь агентством, подобным АНБ, которое пытается использовать Dual EC в качестве лазейки для перехвата сообщений, вам будет намного лучше с системой, которая использует как Dual EC DRBG, так и Extended Random. Поскольку расширенный случайный выбор никогда не был стандартизирован IETF, его не должно быть ни в одной системе. На самом деле, насколько нам известно, BSAFE — единственная система в мире, которая его реализует.
В дополнение к расширенному рандому мы обнаружили множество функций, которые в сочетании с бэкдором Dual EC могут значительно упростить использование RSA BSAFE. Но расширенный случайный выбор, безусловно, самый странный и трудный для оправдания.
Откуда взялся этот стандарт? Для тех, кто любит технические загадки, оказывается, что Extended Random — не единственное забавно пахнущее предложение АНБ. На самом деле это одно из четырех неудачных предложений IETF, сделанных сотрудниками АНБ или подрядчиками, которые тесно сотрудничают с АНБ, и все они пытаются повысить степень случайности в TLS. В этом посте у Томаса Птачека есть умопомрачительно подробное обсуждение этих предложений и его взгляд на их мотивацию.
Боже мой, я никогда не думал, что шпионы могут быть такими
скучными . Какая новая разработка?
Несмотря на то, что мы нашли Extended Random в RSA BSAFE (бесплатную версию, которую мы скачали из Интернета), ложка дегтя заключалась в том, что на самом деле он не был включен . То есть: код был, но переключатели для его включения были жестко закодированы в положение «выключено».
Это вроде как ставит под сомнение нашу теорию о том, что RSA могла включить расширенную случайную выборку, чтобы сделать соединения BSAFE более уязвимыми для АНБ. Может быть какая-то коммерческая версия BSAFE с этим активным кодом, но мы так и не смогли найти его или доказать, что он существует. И что еще хуже, он может появиться только в каком-то специальном «U.S. только для правительства» версия BSAFE, которая могла бы подорвать теорию о том, что было что-то преднамеренное во включении этого кода — в конце концов, зачем правительству шпионить за собой?
Что, наконец, подводит нас к новостям, появившимся на днях в списке рассылки TLS. Оказывается, некоторые принтеры Canon не реагируют должным образом на соединения, выполненные с использованием новой версии TLS (которая называется 1.3), потому что они, похоже, реализовали неавторизованное расширение TLS, используя тот же номер, что и расширение, которое требуется TLS 1. 3 в чтобы правильно работать. Вот соответствующий раздел поста Дэвида:
Веб-интерфейс на некоторых принтерах Canon не работает из-за сообщений ClientHello с поддержкой версии 1.3. Мы приобрели один и подтвердили это с помощью
PIXMA MX492. Согласно сообщениям пользователей, это также влияет на модели PIXMA MG3650
и MX495. Это потенциально влияет на широкий спектр принтеров Canon
.
Эти принтеры используют библиотеку RSA BSAFE для реализации TLS, а эта библиотека
реализует расширение extended_random и присваивает ему номер 9.1219
40. Это конфликтует с расширением key_share и приводит к сбою рукопожатий с поддержкой 1.3
.
Короче говоря, эта новость демонстрирует, что коммерческие (несвободные) версии RSA BSAFE действительно развернули расширение Extended Random и сделали его активным в сторонних коммерческих продуктах. Более того, они развернули его специально для машин — в частности, для готовых коммерческих принтеров — которые, похоже, не предназначены для какого-либо специального государственного использования.
(Если это окажутся специальными принтерами Министерства обороны, я проглотю свои слова.)
По иронии судьбы, теперь принтеры — единственное, что все еще демонстрирует функции этой (теперь устаревшей) версии BSAFE. Это не потому, что АНБ нацеливалось на принтеры. Какие бы устройства они ни нацеливали, вероятно, к настоящему времени их уже нет. Это связано с тем, что прошивка принтера, как правило, устаревает и, тем не менее, очень устойчива. Это похоже на удаленный пул, погребенный под полярным кругом, который сохраняет виды программного обеспечения, которые в противном случае исчезли бы из Интернета.
Что подводит нас к морали этой истории: криптографические лазейки не только ужасная идея, но и полностью портят назначенную систему нумерации для будущих версий вашего протокола .
Вообще-то нет, это довольно бесполезная мораль. Вместо этого давайте просто скажем, что вы можете развернуть криптографический бэкдор, но очень сложно контролировать, где он окажется.
Мэтью Гринин, бэкдоры, Dual EC, RNG, TLS/SSL, Uncategorized 19 декабря 2017 г. 20 декабря 2017 г. 1 479 слов16 комментариев
Большой новостью в криптографии сегодня является атака KRACK на сети Wi-Fi, защищенные WPA2. KRACK ( K ey R einstallation Att ack ) , обнаруженный Мэти Ванхофом и Фрэнком Писсенсом из KU Leuven, KRACK ( K ey R einstallation Att ack ) использует уязвимость в четырехстороннем рукопожатии 802.11i для облегчения расшифровки и подделки атак на зашифрованный WiFi. трафик.
Бумага здесь. Это довольно легко читать, и вы должны.
Я не хочу долго говорить о самом KRACK, потому что уязвимость довольно проста. Вместо этого я хочу поговорить о том, почему эта уязвимость продолжает существовать спустя столько лет после стандартизации WPA. И отдельно, чтобы ответить на вопрос: как эта атака проскочила, несмотря на то, что рукопожатие 802.11i было формально доказано безопасным?
Быстрый TL;DR на KRACK
Подробное описание атаки см. на сайте KRACK или в самой статье. Здесь я просто дам краткое описание высокого уровня.
Протокол 802.11i (также известный как WPA2) включает два отдельных механизма для обеспечения конфиденциальности и целостности ваших данных. Первый — это уровень записи, который шифрует кадры Wi-Fi, чтобы гарантировать, что они не могут быть прочитаны или подделаны. Это шифрование (обычно) реализуется с использованием AES в режиме CCM, хотя есть более новые реализации, использующие режим GCM, и более старые, использующие RC4-TKIP (на данный момент мы их пропустим).
Главное, что нужно знать, это что AES-CCM (и GCM, и TKIP) является потоковым шифром, что означает, что он уязвим для атак, которые повторно используют один и тот же ключ и «одноразовый номер», также известный как вектор инициализации. 48, после чего должно произойти изменение ключа). Это должно предотвратить любое повторное использование одноразового номера при условии, что счетчик номера пакета никогда не может быть равен 9.1218 сброс.
Второй механизм, о котором вам следует знать, — это «четырехстороннее рукопожатие» между точкой доступа и клиентом (запрашивающим лицом), который отвечает за получение ключа, который будет использоваться для шифрования. Конкретное сообщение, о котором заботится KRACK, — это сообщение № 3, которое заставляет новый ключ «устанавливаться» (и использоваться) клиентом.
Я четырехстороннее рукопожатие. Клиент слева, точка доступа справа. (любезно предоставлено Википедией, используется под лицензией CC).
Ключевая уязвимость в KRACK (без каламбура) заключается в том, что подтверждением сообщения №3 может быть заблокирован злоумышленниками.* Когда это происходит, точка доступа повторно передает это сообщение, что приводит к переустановке (того же) ключа в клиенте (примечание: см. обновление ниже*). Это не кажется таким уж плохим. Но как побочный эффект установки ключа, все счетчики номеров пакетов сбрасываются на ноль . (А в некоторых реализациях, таких как Android 6, ключ устанавливается равным нулю — но это другое обсуждение.)
Смысл в том, что, заставляя точку доступа воспроизводить это сообщение, злоумышленник может заставить соединение сбросить одноразовые номера и, таким образом, вызвать ключевой поток. повторное использование в потоковом шифре. При некоторой смекалке это может привести к полной расшифровке потоков трафика. И , что может привести к атакам с перехватом TCP. (Существуют также прямые атаки с подделкой трафика на GCM и TKIP, но пока это пока не так.)
Как это пропустили так долго?
Если вы ищете виноватых, лучше всего начать с IEEE. Чтобы было ясно, я не имею в виду (талантливых) инженеров, разработавших 802.11i — в данных обстоятельствах они проделали довольно хорошую работу. Вместо этого обвиняйте IEEE как институт.
Одна из проблем IEEE заключается в том, что стандарты очень сложны и разрабатываются в ходе закрытого процесса частных встреч. Что еще более важно, даже постфактум им 9 лет.1218 труднодоступен для обычных исследователей безопасности. Поищите в Google спецификации IETF TLS или IPSec. Подробную документацию по протоколу вы найдете в верхней части результатов Google. Теперь попробуйте поискать в Google стандарты 802.11i. Желаю тебе удачи.
IEEE предпринял несколько небольших шагов, чтобы облегчить эту проблему, но это сверхробкая инкременталистская чушь. Существует программа IEEE под названием GET, которая позволяет исследователям бесплатно получать доступ к определенным стандартам (включая 802.11), но только после того, как они станут общедоступными в течение шести месяцев — по совпадению, примерно столько же времени требуется поставщикам, чтобы безвозвратно внедрить их в свое оборудование и программное обеспечение.
Весь этот процесс глуп и — в данном конкретном случае — вероятно, обходится промышленности в десятки миллионов долларов. Это должно прекратиться.
Вторая проблема заключается в том, что стандарты IEEE плохо определены. Как отмечается в документе KRACK, формального описания конечного автомата рукопожатия 802.11i не существует. Это означает, что разработчики должны реализовывать свой код, используя обрывки псевдокода, разбросанные по документу стандартов. Бывает, что этот псевдокод приводит к сломанной реализации, которая включает KRACK. Так что это тоже плохо.
И, конечно же, последняя проблема — разработчики. Одна из действительно ужасных вещей в KRACK заключается в том, что разработчики WPA-соискателя (особенно в Linux) каким-то образом ухитрились сделать Lemon Pledge из лимонов. В частности, в Android 6 воспроизведение сообщения № 3 фактически устанавливает нулевой ключ. За этим стоит внутренняя логика, но Ой Вей. Кому-то действительно нужно посмотреть на этот материал.
Что насчет доказательства безопасности?
Удивительной особенностью рукопожатия 802.11i является то, что, несмотря на все препятствия, которые IEEE ставит на пути людей, оно (по крайней мере, рукопожатие) 91 218 91 219 были официально проанализированы. По крайней мере, для некоторого определения термина.
(Это не я бросаю тень — это констатация фактов. В формальном анализе определения действительно очень важны!) я рукопожатие и попытался определить его свойства безопасности. Они определили, что да, действительно, он создал секретный и надежный ключ, даже когда злоумышленник мог подделать и воспроизвести сообщения (при различных предположениях). Это хорошая, важная работа. Доказательство трудно понять, но это в порядке вещей. Кажется, это правильно.
Представление четырехэтапного рукопожатия из статьи He et al. Да, я знаю, ты такой » что? ». Но именно поэтому у людей, которые занимаются формальной проверкой протоколов, не так много друзей.
Еще лучше, есть другие доказательства безопасности, показывающие, что — при условии, что одноразовые номера никогда не повторяются — режимы шифрования , такие как CCM и GCM, очень безопасны. Это означает, что при наличии безопасного ключа должно быть возможно безопасное шифрование.
Так что же пошло не так?
Критическая проблема заключается в том, что, хотя люди внимательно рассматривали два компонента — рукопожатие и протокол шифрования — по отдельности , очевидно, никто не изучал внимательно эти два компонента, поскольку они были связаны друг с другом. Я почти уверен, что об этом есть целый гик-мем.
Два модульных теста, 0 интеграционных тестов, спасибо Twitter.
Конечно, причина, по которой никто не присматривался к этому материалу, заключается в том, что это всего лишь простой жесткий . Протоколы имеют экспоненциальное количество возможных случаев для анализа, и мы почти достигли предела сложности протоколов, о которых люди могут по-настоящему рассуждать или которые могут проверить рецензенты. Чем больше кусочков вы добавляете в смесь, тем хуже становится эта проблема.
В конце концов, мы все знаем, что люди должны перестать делать эту работу. Нам нужна машинная проверка протоколов, предпочтительно привязанная к фактическому исходному коду, который их реализует . Это гарантировало бы, что протокол действительно делает то, что он говорит, и что разработчики не испортят его еще больше, что сделает доказательство безопасности недействительным.
Это нужно сделать срочно, но мы так рано придумываем, как это сделать , что неясно, что нужно сделать, чтобы все это заработало. В целом, это область, которая могла бы использовать лот больше работы. Надеюсь, я доживу до этого.
===
* Обновление: В ранней версии этого поста предполагалось, что злоумышленник воспроизведет третье сообщение. Это действительно может произойти, и это действительно происходит в некоторых более сложных атаках. Но прежде всего в документе описывается принуждение точки доступа к повторной отправке путем блокирования получения подтверждения на точке доступа. Спасибо Никите Борисову и Кайлу Биркеланду за исправление!
Мэтью Гринин Без рубрики 16 октября 2017 г. 17 октября 2017 г. 1 391 Words28 Комментарии
Цены | Служба управления ключами AWS (KMS)
Хранилище ключей
Каждый ключ AWS KMS, который вы создаете в AWS KMS, стоит 1 доллар США в месяц (пропорционально почасово). Плата в размере 1 доллара США в месяц одинакова для симметричных ключей, асимметричных ключей, ключей HMAC, ключей для нескольких регионов (каждый первичный ключ и каждая реплика для нескольких регионов), ключей с импортированным материалом ключа и ключей KMS с источником ключа AWS. CloudHSM или внешнее хранилище ключей (XKS).
Если вы включите автоматическую смену ключей, каждый вновь созданный резервный ключ будет стоить дополнительно 1 доллар США в месяц (пропорционально почасово). Это покрывает затраты AWS KMS на сохранение всех версий материала ключа, чтобы их можно было использовать для расшифровки старых зашифрованных текстов.
Плата не взимается за следующее:
Создание и хранение ключей KMS, управляемых AWS или принадлежащих AWS. Эти ключи автоматически создаются от вашего имени при первой попытке зашифровать ресурс в сервисе AWS, который интегрируется с AWS KMS. Вы не можете ни управлять жизненным циклом, ни правами доступа к управляемым ключам AWS.
Плата за управляемые клиентом ключи KMS, которыми вы управляете и которые запланированы к удалению, не взимается. Если вы отмените удаление в течение периода ожидания, за ключ KMS, управляемый клиентом, будет взиматься плата, как если бы он никогда не планировался к удалению.
Ежемесячная плата за ключи данных или пары ключей данных, которые генерирует AWS KMS, не взимается, кроме платы за вызов API.
Использование ключа
{{#if kms/kms.[API request — Non Free Tier]}}
{{loc-currency (math kms/kms.[API request — Non Free Tier].[price] «times» 10000)}}{{else}}>{{loc-message «N/A»}}{ {/if}} на 10 000 запросов
{{/if}} {{#if kms/kms.[Асимметричные запросы RSA_2048]}}
{{loc-currency (math kms/kms. [Асимметричные запросы RSA_2048].[price] «times» 10000)}}{{else}}>{ {loc-message «N/A»}}{{/if}} на 10 000 запросов с использованием ключей RSA 2048
{{/if}} {{#if kms/kms.[API Requests GenerateDatakeyPair ECC]}}
{{loc-currency (math kms/kms.[API Requests GenerateDatakeyPair ECC].[price] «times» 10000)}}{{else}} >{{loc-message «N/A»}}{{/if}} на 10 000 запросов ECC GenerateDataKeyPair
{{/if}} {{#if kms/kms.[Асимметричные запросы, кроме RSA_2048API]}}
{{loc-currency (math kms/kms.[Асимметричные запросы, кроме RSA_2048API].[price] «times» 10000)}}{{else}} >{{loc-message «N/A»}}{{/if}} на 10 000 асимметричных запросов, кроме RSA 2048
{{/if}} {{#if kms/kms.[API Requests GenerateDatakeyPair RSA]}}
{{loc-currency (math kms/kms.[API Requests GenerateDatakeyPair RSA].[price] «times» 10000)}}{{else}} >{{loc-message «N/A»}}{{/if}} на 10 000 запросов RSA GenerateDataKeyPair
{{/if}}
Примечание 1. Хотя плата за создание и хранение ключей, управляемых AWS, не взимается, с вас будет взиматься плата за любой запрос API к ключам, управляемым AWS.
Примечание 2. При использовании ключа KMS в другой учетной записи AWS плата за использование ключа взимается с учетной записи AWS, отправляющей запрос API.
Использование CloudHSM или внешнего хранилища ключей (XKS)
У вас есть возможность использовать кластер AWS CloudHSM или внешний диспетчер ключей для создания и хранения ключей KMS. Эти ключи также будут стоить 1 доллар в месяц (пропорционально почасово). При использовании AWS CloudHSM взимается стандартная плата за использование AWS CloudHSM. См. этот пример ценообразования.
Уровень бесплатного пользования
AWS KMS предоставляет уровень бесплатного пользования в размере 20 000 запросов в месяц, рассчитанный для всех регионов, в которых доступен сервис.
*Запросы к операциям API GenerateDataKeyPair и GenerateDataKeyPairWithoutPlaintext, а также запросы к операциям API, таким как Sign, Verify, Encrypt, Decrypt и GetPublicKey, которые ссылаются на асимметричные ключи KMS, исключаются из бесплатного уровня.
Примеры цен
Пример Amazon EBS
1 ключ KMS, используемый в качестве корневого ключа при создании 250 зашифрованных томов EBS в месяц с помощью операций интерфейса командной строки или API AWS KMS.
Размеры стоимости:
1 ключ KMS
3 X 250 запросов API для создания и предоставления уникального ключа шифрования данных для каждого из 250 томов

Стоимость в месяц:
1,00 долл. США 1 ключ KMS
0,00 $ 0 запросов (750 запросов — 20 000 запросов уровня бесплатного пользования)
Итого:
1 доллар в месяц
Пример Amazon S3
1 ключ KMS, используемый для шифрования 10 000 уникальных файлов, которые коллективно расшифровываются для доступа 2 000 000 раз в месяц.
Размеры стоимости:
1 ключ KMS
10 000 запросов на шифрование (1 запрос x 10 000 объектов)
2 000 000 запросов на дешифрование для доступа к объектам
Стоимость в месяц:
1 доллар США 1 ключ KMS
5,97 $ 1 990 000 запросов (всего 2 010 000 запросов — 20 000 запросов на уровне бесплатного пользования) x 0,03 USD / 10 000 запросов
Итого:
6,97 долл. США в месяц
Пример Amazon S3: использование пользовательского хранилища ключей с CloudHSM
1 ключ KMS используется для шифрования 10 000 уникальных файлов, которые совместно расшифровываются для доступа 2 000 000 раз в месяц. Кластер CloudHSM, содержащий 2 модуля HSM, поддерживается на востоке США (Северная Вирджиния) в течение всего месяца.
Размеры стоимости:
1 ключ KMS
10 000 запросов на шифрование (1 запрос x 10 000 объектов)
2 000 000 запросов на дешифрование для доступа к объектам
2 экземпляра CloudHSM
Стоимость в месяц:
1 доллар США 1 ключ KMS
5,97 $ 1 990 000 запросов (всего 2 010 000 запросов — 20 000 запросов на уровне бесплатного пользования) x 0,03 USD / 10 000 запросов
2 380,80 $ 31 день для 2 модулей HSM x 1,60 долл. США за модуль HSM в час
Итого:
2 387,77 долл. США в месяц
1 ключ ECC 256 KMS, используемый для подписи 100 000 файлов через интерфейс командной строки AWS KMS или операции API.
Стоимость Размеры:
1 Ключ KMS
100 000 запросов на подпись
Стоимость в месяц:
1 доллар США 1 ключ KMS
1,50 долл. США 100 000 запросов по цене 0,15 доллара США за 10 000 запросов
Итого:
2,50 долл. США в месяц
Если вы включите AWS CloudTrail в своей учетной записи, вы сможете получать журналы вызовов API, сделанных в AWS KMS или с помощью AWS KMS. Дополнительную информацию см. на странице цен на AWS CloudTrail.
Узнайте, как начать работу
Найдите ссылки на наше руководство для разработчиков, полезные видеоролики и руководства по работе с консолью.
Подробнее
Создайте бесплатную учетную запись
Мгновенно получите доступ к уровню бесплатного пользования AWS.
Зарегистрироваться
Начните сборку в консоли
Начните сборку с помощью службы управления ключами AWS в консоли AWS.
Войдите в систему
Войдите в консоль
Узнайте об AWS
Что такое AWS?
Что такое облачные вычисления?
AWS Разнообразие, равенство и инклюзивность
Что такое DevOps?
Что такое контейнер?
Что такое озеро данных?
Облачная безопасность AWS
Что нового
Блоги
Пресс-релизы
Ресурсы для AWS
Начало работы
Обучение и сертификация
Библиотека решений AWS
Архитектурный центр
Часто задаваемые вопросы по продуктам и техническим вопросам
Аналитические отчеты
Партнеры AWS
Разработчики на AWS
Центр разработчиков
SDK и инструменты
. NET на AWS
Python на AWS
Java на AWS
PHP на AWS
JavaScript на AWS
Помощь
Свяжитесь с нами
Подать заявку в службу поддержки
Центр знаний
AWS re: Сообщение
Обзор поддержки AWS
Юридический
Карьера в AWS
Amazon является работодателем с равными возможностями: Меньшинства / женщины / инвалиды / ветераны / гендерная идентичность / сексуальная ориентация / возраст.
Конфиденциальность
|
Условия сайта
|
Настройки файлов cookie
|
© 2023, Amazon Web Services, Inc. или ее дочерние компании. Все права защищены.
Поддержка AWS для Internet Explorer заканчивается 31. 07.2022. Поддерживаемые браузеры: Chrome, Firefox, Edge и Safari. Узнать больше »
RC4 NOMORE
Введение
Когда вы посещаете веб-сайт и в адресной строке браузера отображается значок замка , протокол HTTPS используется для защиты вашего взаимодействия с этим веб-сайтом (обеспечивая безопасность и конфиденциальность). HTTPS поддерживает несколько методов шифрования, одним из которых является знаменитый алгоритм RC4. В какой-то момент RC4 использовался в 50% случаев, при этом оценка примерно в феврале 2015 г. составляла 30%. Наша атака RC4 NOMORE выявляет слабые места в этом алгоритме шифрования RC4. Точнее, в большинстве ситуаций, когда используется RC4, эти уязвимости можно использовать для раскрытия информации, которая ранее считалась надежно зашифрованной.
В частности, мы показываем, что злоумышленник может расшифровать веб-куки , которые обычно защищены протоколом HTTPS. Веб-сайты используют эти файлы cookie для идентификации пользователей и авторизации действий, которые они выполняют. Получив файл cookie жертвы, злоумышленник может войти на веб-сайт, как если бы он был жертвой. Это означает, что злоумышленник может выполнять действия от имени жертвы (например, публиковать обновления статуса и отправлять сообщения), получать доступ к личной информации (например, к электронной почте и истории чата) и так далее.
Исследование атаки было представлено на USENIX Security. Подводя итог, злоумышленник может расшифровать файл cookie в течение 75 часов. В отличие от предыдущих атак, это короткое время выполнения позволяет нам провести атаку на практике. Когда мы протестировали атаку на реальных устройствах, потребовалось всего 52 часа для успешного проведения атаки. Атака состоит из трех этапов:
Когда жертва посещает незашифрованный веб-сайт, злоумышленник вставляет внутрь веб-сайта вредоносный код JavaScript. Этот код заставит жертву передавать зашифрованные запросы, содержащие веб-куки жертвы. Отслеживая многочисленные из этих зашифрованных запросов, можно восстановить список вероятных значений файлов cookie. Все файлы cookie в этом списке проверяются до тех пор, пока не будет найден правильный.
Обновление за октябрь 2017 г.: Мы рады сообщить, что вместе с другими работами над RC4 наша работа повлияла на отключение RC4 в основных браузерах. В результате использование RC4 резко сократилось: менее 1% всех соединений HTTPS и TLS по-прежнему используют RC4.
Демонстрация
В качестве проверки концепции мы провели атаку в нашей лаборатории на вымышленный веб-сайт и жертву (чтобы не нанести вред реальным системам). В нашей демонстрации жертва использует Internet Explorer, и мы показываем, как злоумышленник может завладеть учетной записью жертвы. это первый раз слабые места в RC4 при использовании в TLS и HTTPS эксплуатируются против реальных устройств .
Чтобы успешно расшифровать 16-символьный файл cookie с вероятностью успеха 94%, необходимо зафиксировать примерно 9⋅2 ²⁷ шифровок файла cookie. Поскольку мы можем заставить клиента передавать 4450 запросов в секунду, это количество можно собрать всего за 75 часов. Если злоумышленнику повезет, потребуется захватить меньше шифров. В нашей демонстрации для выполнения атаки хватило 52 часов, после чего 6,2⋅2 ²⁷ запросов было перехвачено. Генерацию этих запросов можно даже растянуть во времени: их не нужно захватывать все сразу. На последнем этапе атаки перехваченные запросы преобразуются в список из 2 ²³ вероятных значений cookie. Все файлы cookie в этом списке можно протестировать менее чем за 7 минут.
Наша атака не ограничивается расшифровкой файлов cookie . Любые данные или информация, которые неоднократно шифровались, могут быть восстановлены. Мы фокусируемся на веб-куки в HTTPS, поскольку это прекрасно иллюстрирует слабые стороны RC4 и силу нашей атаки.
Документ
Наш исследовательский документ, стоящий за атакой, называется «Все ваши предубеждения принадлежат нам: взлом RC4 в WPA-TKIP и TLS». В статье представлены атаки не только на TLS/HTTPS, но и на WPA-TKIP. Наша атака на WPA-TKIP выполняется всего за час и позволяет злоумышленнику внедрить и расшифровать произвольные пакеты. На этой странице мы сосредоточились на HTTPS, потому что он используется чаще, чем WPA-TKIP. Документ был представлен на USENIX Security 2015, и вы можете просмотреть слайды онлайн.
Мы также хотели бы отметить, что существует независимый перевод нашей статьи на испанский язык.
Вопросы и ответы
Чем эта атака отличается от предыдущих атак?
По оценкам, первая атака на RC4, используемую в TLS, заняла более 2000 часов. Для его расшифровки требовалось 13⋅2 ³⁰ шифрований файла cookie, и жертва могла генерировать 1700 запросов в секунду (каждый запрос содержал зашифрованный файл cookie). Нам нужно всего 9⋅2 ²⁷ запросов и может заставить жертву генерировать 4450 запросов в секунду. Это означает, что наша атака занимает всего 75 часов. Мы также протестировали атаку на реальных устройствах, в то время как в предыдущих работах выполнялось только моделирование.
Атака Bar Mitzvah опирается на потоки ключей с предсказуемыми младшими битами, которые происходят один раз каждые 2 ²⁴ соединений. Известно, что только первые 100 байтов ключевого потока являются слабыми. Однако в настоящее время неизвестны системы, которые шифруют конфиденциальные данные в этих позициях.
Еще одна атака нацелена на пароли, зашифрованные с помощью RC4, и основана на статистической погрешности в начальных байтах ключевого потока. Для его расшифровки требуется примерно 2 ²⁶ шифрований пароля. Однако создание большого количества запросов в этом сценарии оказывается затруднительным, поскольку каждый запрос должен выполняться в новом соединении TLS. По их оценкам, для выполнения атаки требуется от 312 до 776 часов.
Наша работа значительно сокращает время выполнения атаки, и мы считаем это улучшение очень тревожным. Учитывая, что по-прежнему существуют неиспользованные предубеждения, что можно реализовать более эффективные алгоритмы и изучить лучшие методы генерации трафика, мы ожидаем дальнейших улучшений в будущем.
Какие недостатки в RC4 используются для атаки?
Он основан на двух типах статистических погрешностей, присутствующих в ключевом потоке. Первый заключается в том, что два последовательных байта смещены в сторону определенных значений. Их обычно называют предубеждениями Флюрера-МакГрю. Второй тип смещений заключается в том, что пара последовательных байтов может повторяться. Они называются предубеждениями ABSAB Мантина. В нашей атаке сочетаются оба типа предубеждений.
Эти предубеждения позволяют нам расшифровывать повторяющихся открытых текстов, таких как файлы cookie.
Что теперь?
Единственная хорошая контрмера — прекратить использование RC4. Тем не менее, мы заметили, что создание необходимого объема трафика может быть узким местом при выполнении атаки. Следовательно, атаки можно сделать более дорогими, но не предотвратить, затруднив генерацию трафика. Один из вариантов — запретить браузерам создавать параллельные соединения при использовании RC4 (обычно для более быстрой загрузки веб-сайтов создаются несколько соединений). Это снижает скорость, с которой клиенты могут выполнять запросы, а значит, они медленнее генерируют трафик. Однако подчеркнем, что это лишь увеличит время выполнения атак, а не предотвратит их.
WPA-TKIP также уязвим?
Да. Мы можем взломать сеть WPA-TKIP в течение часа. Точнее, после успешного выполнения атаки злоумышленник может расшифровать и внедрить произвольные пакеты, отправленные клиенту. В общем, любой протокол, использующий RC4, следует считать уязвимым.
Ресурсы
Более подробные версии нескольких графиков представлены в нашей статье:
Распределение байтов ключевого потока с 258 по 513 (на позицию).
Распределение байтов ключевого потока с 258 по 513 (на значение).
Подробный график смещений Fluhrer-McGrew в начальных байтах ключевого потока (рисунок 4 в документе).
Подробный график влияния первых двух байтов ключевого потока (рисунок 5 в статье).
Несмотря на то, что полная статистика ключевого потока слишком велика, чтобы ее можно было разместить в Интернете, мы предоставляем наборы данных по большинству обнаруженных нами предубеждений:
Статистика начальных 513 байтов ключевого потока, рассчитанная с использованием примерно 2 ^47,18 ключей RC4.
Статистика влияния первого байта потока ключей и влияния второго байта потока ключей, рассчитанная с использованием приблизительно 2 ^44,19 ключей RC4. Формат этих файлов и код для их простого чтения можно найти в этом файле Python.
Статистика по первым 512 последовательным байтам ключевого потока, рассчитанная с использованием примерно 2 ^45.01 Ключи RC4. Формат файла и код для его легкого чтения можно найти в этом файле Python.
Наконец, вы также можете загрузить нашу R-реализацию М-теста Фукса и Кенетта.
Creative Commons Attribution 4.0 Международная лицензия | Дизайн вдохновлен TEMPLATED.
Служба управления ключами Amazon | Управление ключами шифрования
Уровень бесплатного пользования
Уровень бесплатного пользования KMS доступен в регионе Amazon Web Services China (Ningxia) под управлением NWCD и в регионе Amazon Web Services China (Пекин) под управлением Sinnet. Уровень бесплатного пользования включает 20 000 бесплатных запросов в месяц.
Подробнее »
Хранилище ключей
Каждый мастер-ключ клиента (CMK), который вы создаете в Amazon Key Management Service (KMS), стоит 6,88 йен в месяц до тех пор, пока вы не удалите его, независимо от того, где находился базовый материал ключа. созданный службой, пользовательским хранилищем ключей или импортированным вами. Для CMK с ключевым материалом, созданным службой, если вы согласились на автоматическую смену ключа каждый год, каждая новая версия ключа увеличивает стоимость CMK на 6,88 иен в месяц. Amazon KMS сохраняет и управляет каждой предыдущей версией CMK, чтобы убедиться, что вы можете расшифровать данные, зашифрованные в предыдущих версиях. За пары ключей данных, которые создаются запросами API GenerateDataKeyPair и GenerateDataKeyPairWithoutPlaintext, взимается плата за эти запросы API в соответствии с расценками на использование, описанными ниже. С вас не взимается ежемесячная плата за сами пары ключей данных, поскольку они не хранятся и не управляются службой. В месяц создания ключа ежемесячная плата за хранение ключа в размере 6,88 йены будет пропорциональна ближайшему полному часу.
Плата не взимается за следующее:
Создание и хранение CMK, управляемых Amazon Web Services. Эти ключи автоматически создаются от вашего имени при первой попытке зашифровать ресурс в сервисе Amazon Web Services, который интегрируется с Amazon KMS. Вы не можете ни управлять жизненным циклом, ни правами доступа к управляемым ключам Amazon Web Services.
Созданные вами ключи CMK, управляемые клиентом, которые планируется удалить. Если вы отмените удаление в течение периода ожидания, с CMK будет взиматься плата, как если бы удаление никогда не планировалось.

Использование ключа
Стоимость каждого запроса API к службе управления ключами Amazon:
Все регионы Китая:
0,20 иены за 10 000 запросов (все API, кроме асимметричного API)
0,20 иены за 10 000 запросов ключей RSA 2048
0,60 иены за 10 000 запросов ECC GenerateDataKeyPair
1,00 иены за 10 000 асимметричных запросов, кроме RSA 2048
72,00 иен за 10 000 запросов RSA GenerateDataKeyPair
Примеры цен
Пример Amazon EBS
1 CMK используется в качестве ключа KMS, управляемого клиентом, при создании 2500 зашифрованных томов EBS в месяц с помощью CLI или API Amazon KMS.
Стоимость Размеры:
1 CMK
3 X 2500 запросов API для создания и предоставления уникального ключа шифрования данных для каждого из 2500 томов

Стоимость в месяц:
6,88 иен 1 СМК
0,15 йен (0,2 йены за 10 000 вызовов API) * 7500 вызовов
Итого:
7,03 иен /месяц
Amazon S3 Пример
1 CMK используется для шифрования 10 000 уникальных файлов, которые совместно расшифровываются для доступа 2 000 000 раз в месяц.
Стоимость Размеры:
1 CMK
10 000 запросов шифрования (1 запрос * 10 000 объектов)
2 000 000 Расшифровать запросы на доступ к объектам

Стоимость в месяц:
6,88 иен 1 СМК
40,2 йен Всего 2 010 000 запросов * 0,2 йены / 10 000 запросов
Итого:
47,08 йен /месяц
Пример приложения для подписи файлов
1 ECC 256 CMK используется для подписи 100 000 файлов через CLI или API Amazon KMS.
Стоимость Размеры:
1 CMK
100 000 запросов на подпись

Стоимость в месяц:
6,88 иен 1 СМК
10,0 иен 100 000 запросов по 1,0 иены за 10 000 асимметричных запросов
Итого:
16,88 иен /месяц
Если вы включите Amazon CloudTrail в своей учетной записи, вы сможете получать журналы вызовов API, сделанных Amazon KMS или отправленных им. Дополнительную информацию см. на странице цен на Amazon CloudTrail.
Узнайте, как начать работу
Найдите ссылки на наше руководство для разработчиков, полезные видеоролики и руководства по работе с консолью.
No related posts.

Welcome to Catch Magazine

Аббревиатуры в логистике/Viconte Marine

Авиационные сокращения

Общий анализ мочи при цистите

Какой анализ мочи нужен при цистите

Подготовка к сдаче ОАМ при цистите

Как правильно собирать анализ мочи при цистите

Что показывает анализ мочи при цистите

Расшифровка общего анализа мочи при цистите

Где можно сдать анализ мочи при цистите

WMS система управления складом — что это

Что такое WMS-система управления складом?

Преимущества внедрения WMS-системы управления складом:

Наличие исчерпывающих актуальных данных для принятия быстрых решений

Повышение скорости выполнения заказов

Снижение затрат на складскую обработку

Минимизация ошибок

Экономия времени

Несколько простых советов по внедрению системы штрихкодирования:

Функционал WMS-системы управления складом:

Приемка товара

Учет товара

Оптимизация процесса хранения

Управление персоналом

Документооборот

Комплектация и отгрузка

Обслуживание клиентов

Управление складом и контроль

Отчетность

Как выбрать WMS-систему управления складом:

Полезная информация

История успеха

Новости

Новости партнеров

Ваш консультант:

Наши клиенты

Награды и достижения

Условия поставки FCA (Free Carrier) Инкотермс 2010 (актуально на 2017)

Что означает FCA: расшифровка

Дополнительная терминология для FCA

Базис и условия поставки FCA

Распределение рисков и обязанностей

Обязанности и риски продавца (поставщика)

Обязанности и риски покупателя

Переход права собственности и рисков

Кто оформляет CMR?

Что такое франко-перевозчик?

Договор поставки на условиях FCA

Цена на условиях FCA

Принцип классификации судов РКО (выдержка из правил)

Принцип классификации судов РКО (выдержка из правил)

Математика | Бесплатный полнотекстовый | Генерация распределенного ключа на основе R-LWE и дешифрование порога

1. Введение

1.1. State-of-the-Art

1.2. Вклады

1.3. Структура

2. Предварительные

2.1. Обозначение

2.2. Криптографические примитивы

2.3. Распределенная криптография

2.4. Кольцевое обучение с ошибками

3. Схема шифрования и протоколы

4. Корректность

5. Безопасность

5.1. Безопасность схемы шифрования

5.2. Отсутствие утечки информации

6. Реализация

6.1. Выбор параметров

6.

6.3. Результаты моделирования

7. Выводы и будущая работа

Вклад авторов

Финансирование

Заявление Институционального контрольного совета

Заявление об информированном согласии

Заявление о доступности данных

Конфликт интересов

Сокращения

Приложение А.2. Безопасность

Приложение Б. Доказательства вспомогательных теорем и лемм